build: INFENG-938: Update version format in Makefiles #10142
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ticket
INFENG-938
Description
Add an optional
v
in the grep regular expression that computes previous version tags in GoReleaser Makefile targets for master, agent, and helm. This ensures continuity between the previous tag format, which used bare version strings, and the new tag format, all of which begin with a literalv
. Otherwise, when trying to derive a previous tag that begins with av
, the grep would fail.Note that things would still otherwise work fine for the next release, because previous tags would still satisfy the format. Subsequent releases, however, would be incorrect, because the tag would begin with a
v
and thus not match.GORELEASER_PREVIOUS_TAG
is used for determining which release notes to include, and having it set incorrectly would cause problems for the GitHub release.Test Plan
There are a few different cases to test. First, we'll test the upcoming case, which is: an rc release with the new tag style, against an existing minor release with the old tag style.
HEAD
:git tag v0.38.0-rc0
.export VERSION='v0.38.0-rc0
. Note: it must match the tag. This is necessary to mimic the make target command that setsGORELEASER_PREVIOUS_TAG
, although it does require that the tag actually exists.git tag --sort=-creatordate | grep "${VERSION}" -A1 | sed -n '2 p'
, to test the behavior ofGORELEASER_PREVIOUS_TAG
for therelease-gh-rc
make target.0.37.0
, which is the correct previous tag for a release candidate build.git tag -d v0.38.0-rc0
.Next, test the case where we have a new rc tag, after a previous rc tag.
HEAD~1
:git tag v0.38.0-rc0 HEAD~1
.HEAD
:git tag v0.38.0-rc1
.export VERSION='v0.38.0-rc1'
.git tag --sort=-creatordate | grep "${VERSION}" -A1 | sed -n '2 p'
, to test the behavior ofGORELEASER_PREVIOUS_TAG
for therelease-gh-rc
make target.v0.38.0-rc0
, as that is, indeed, the previous tag.git tag -d v0.38.0-rc0 v0.38.0-rc1
.Next, test the case where we have a new minor tag, while the previous tag is using the old tag format. The output should be the previous non-rc tag (in our case, a minor release tag).
HEAD~2
:git tag v0.38.0-rc0 HEAD~2
.HEAD~1
:git tag v0.38.0-rc1 HEAD~1
.HEAD
:git tag v0.38.0
.export VERSION='v0.38.0'
.git tag --sort=-creatordate | grep -E '^v?[0-9.]+$$' | grep "${VERSION}" -A1 | sed -n '2 p'
, to simulate therelease-gh
make target.0.37.0
, which is the correct previous non-rc tag.git tag -d v0.38.0-rc0 v0.38.0-rc1 v0.38.0
.Finally, test the case where we have a new minor release tag, with the previous tag also using the new tag format. The output should be the previous non-rc tag using the new format.
HEAD~2
:git tag v0.38.0 HEAD~2
.HEAD~1
:git tag v0.39.0-rc0 HEAD~1
.HEAD
:git tag v0.39.0
.export VERSION='v0.39.0'
.git tag --sort=-creatordate | grep -E '^v?[0-9.]+$$' | grep "${VERSION}" -A1 | sed -n '2 p'
, to simulate therelease-gh
make target.v0.38.0
, which is the correct previous non-rc tag with the new format.git tag -d v0.38.0 v0.39.0-rc0 v0.39.0
.Note: please ensure that all of your local testing tags are cleaned up!
Checklist
docs/release-notes/
See Release Note for details.