chore(ci): rename release branch image's tag

[mwangggg]

fixes: #39

[mwangggg]

https://github.com/mwangggg/cryostat-grafana-dashboard/actions/runs/6733847443/job/18303438072

[andrewazores]

So with this, the pushed branch name is used:

• main -> main + latest
• cryostat-vX.Y -> X.Y.0

Right?

I think that's a good enough improvement. I might prefer to have cryostat-vX.Y -> X.Y. X.Y.0, X.Y.1 would be better to do using git tags somehow.

[mwangggg]

https://github.com/mwangggg/cryostat-grafana-dashboard/actions/runs/6736134387/job/18310819993

[andrewazores]

Oh, I meant that the .0 and .1 tags should not normally be applied. If there is a push to the branch cryostat-v2.4 then this should result in the image only being tagged as 2.4, not as 2.4.0 or 2.4.1. The 2.4.0 and 2.4.1 image tags would ideally be created somehow based on git tags.

I'm imagining a workflow where we cut a release branch like cryostat-v2.4 off of main. Any push to cryostat-v2.4 (ex. PRs getting backported) would result in the 2.4 image tag getting bumped up to the most recent image built from that branch. Image tags like 2.4.0 and 2.4.1 would be additionally applied to container images if they are built from commits that have a git tag like 2.4.0 or 2.4.1 on them. So at some point in time, there would be a container image tagged as both 2.4 and 2.4.0. If another backport goes into the cryostat-v2.4 branch, then the 2.4 tag would get updated and point to that newer container image, but 2.4.0 would remain on the previous one that was built from the specific commit with that git tag.

I think git describe --tags --exact-match sounds like it would be useful for this (man git-describe).

$ pwd
/home/work/workspace/cryostat-grafana-dashboard
$ git describe --tags --exact-match
fatal: no tag exactly matches 'd3a5158a827f34e205eea6ef5512737e66c3c229'
$ git tag
1.0.0-BETA4
v1.0.0
v2.1.0
v2.3.0
$ git checkout v2.3.0
$ git describe --tags --exact-match
v2.3.0

So something like git describe --tags --exact-match 2>/dev/null || echo -n '' can be run. If the current commit exactly matches a git tag, then that git tag's name is output to stdout. Otherwise it's the empty string.

[mwangggg]

ohhh I thought the period was a comma. Time to get glasses

[andrewazores]

If Elliott also agrees on tagging container images using git tags this way then we should do the same or similar across all of our repos that produce container images, too. This makes the release process a little easier/more automated, and keeps it consistent across repos.

[ebaron]

I'm a little concerned with using something like 2.4 to represent a development build. I would naively expect that tag to point to whatever the latest 2.4.x release is. Keeping some kind of suffix like -dev or -snapshot would make this distinction a lot more obvious.

[andrewazores]

That's fair. We could have pushes to the branch cryostat-vX.Y tag images as X.Y-dev, and then create X.Y.0 and X.Y.1 image tags using git tags.

We could leave it at that, or we could add a small snippet of JS or shell code that also tags the image as X.Y whenever the push corresponds to a git tag X.Y.Z. That could go another step further and also add the image tag X.