-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ENGINE-978] Change revision scheme per ENGINE-970 requirements #5
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: plaurent <[email protected]>
9be1228
to
0bf7237
Compare
tests/version.go
Outdated
regex, err := regexp.CompilePOSIX("^v[0-9]+.[0-9]+.[0-9]+(m[0-9]+|m[0-9]+-rc[0-9]+|m[0-9]+-tp[0-9]+)$") | ||
require.True(t, err == nil && regex.MatchString(version), "Second field was not valid: %+v", version) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
regex, err := regexp.CompilePOSIX("^v[0-9]+.[0-9]+.[0-9]+(m[0-9]+|m[0-9]+-rc[0-9]+|m[0-9]+-tp[0-9]+)$") | |
require.True(t, err == nil && regex.MatchString(version), "Second field was not valid: %+v", version) | |
regex := regexp.MustCompilePOSIX("^v[0-9]+.[0-9]+.[0-9]+(m[0-9]+|m[0-9]+-rc[0-9]+|m[0-9]+-tp[0-9]+)$") | |
require.True(t, regex.MatchString(version), "Second field was not valid: %+v", version) |
hack/build
Outdated
: "${PRERELEASE=$(./hack/git-meta version | rev | cut -c3- | rev | cut -d'-' -f 2 | grep -E '(^tp|^rc).*')}" | ||
: "${REVISION_NUMBER=1}" | ||
VERSION=$(printf "v%sm%s%s" "$(./hack/git-meta version | rev | cut -c3- | rev | cut -d'-' -f 1 | cut -c2-)" "${REVISION_NUMBER}" "-${PRERELEASE}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please explain what this is doing and why it is necessary? Why does the m-version need to be sourced from an environment variable? Why can't we just include the m-version part in our git tags?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By m-version, I assume you mean the REVISION_NUMBER. I was under the impression that was going to be included from the pipeline going forward.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The package revision is going to be provided from the packaging pipeline going forward. I don't think it makes sense for the packaging pipeline to pass the software version into the build script piecemeal. @aepifanov's release process proposal -- which you reviewed with the rest of the team -- is for the packaging pipeline to take a Git tag name as a parameter and use the tag name as the version of the software being built. Since the tag is going to encode the full software version; revision, prerelease and all; there would be little value in passing the version components separately. The pipeline would have to parse the version string, only to have the build script re-concatenate it into an identical string.
Note that we will be creating multiple tags which reference the same commit, e.g. to rebuild an RC as a GA. That means we can't rely on the hack/git-meta version
command. It looks for which tags reference the commit, but if more than one tag references the commit it might choose the wrong tag. This hack/build
script already affords overriding the automatically inferred software version by setting the VERSION
environment variable. Why not simply leverage that, and have our packaging script set VERSION
to the git tag name when invoking the build?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The proposal doesn't have much detail regarding buildx.
Signed-off-by: plaurent <[email protected]>
This is a PR in order to change the versioning scheme to utilize the upstream buildx version along with the PRERELEASE and REVISIONS schemes described in ENGINE-970.