-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
[v1.13] ci/ipsec: Fix downgrade version for release preparation commits #30715
[v1.13] ci/ipsec: Fix downgrade version for release preparation commits #30715
Conversation
qmonnet
commented
Feb 12, 2024
- contrib/scripts: Remove special handling for patch release number 90 #30413
- ci/ipsec: Fix downgrade version for release preparation commits #30532
[ upstream commit 4d7902f ] In commit 56dfec2 ("contrib/scripts: Support patch releases in print-downgrade-version.sh"), we added support to disaply the previous patch release for a given version number to the print-downgrade-version.sh script. We treated to patch release values as special cases: 0, because this means that we don't have a previous patch release on the branch, and 90, because it used to be a temporary value used during release processes. But as Joe commented, we no longer use this "90" convention, but we use something like vX.Y.Z-dev instead. Let's remove the reverence to 90 from the script (and the workflow calling it). Comparing with the commit introducing the special cases in the script, the output remains nearly the same as when it was introduced, only the previous patch release for "1.13.90" naturally turns to "1.13.89" instead of providing an error. VERSION Previous minor Previous patch release 1.14.3 v1.13 v1.14.2 1.14.1 v1.13 v1.14.0 1.14.0 v1.13 <error> 1.14.1-dev v1.13 v1.14.0 1.15.0-dev v1.14 <error> 1.13.90 v1.12 v1.13.89 Reported-by: Joe Stringer <joe@cilium.io> Signed-off-by: Quentin Monnet <quentin@isovalent.com>
/test-backport-1.13 |
[ upstream commit 3803f53 ] For the IPsec upgrade/downgrade CI test, for the jobs where we upgrade/downgrade to the closest patch release, the script print-downgrade-version.sh determines the patch release by picking up the value in file VERSION. This works most of the time. For release preparation commits, however, this approach fails because the reference in VERSION points to a release that has not been tagged or published yet. We need to pick the previous patch release in that case. However, it's non-trivial to figure out whether we're on a release preparation commit, in particular because the CI workflow does a shallow Git clone and we don't have access to the Git history. I couldn't find an ideal solution, so this commit changes the shallow-clone and makes it fetch the tags, as well, so that we're allow to check for the tag existence before returning it. If the tag is not available, we decrement the patch version found in VERSION before computing the patch release to downgrade to. Note that we do not expect this second attempt (with the patch release number decremented) to fail, so we do not check for its existence in the Git history: if we did, and printed an error in the script but returned an empty value, we'd skip the rest of the CI workflow. Instead, if we're in a situation where this decremented patch release number is returned but is not a valid one, CI will attempt to run the workflow with it, and fail loudly, which is what we want in that case. Sample output from the script: VERSION Prevous minor Previous patch release 1.14.3 v1.13 v1.14.3 1.14.1 v1.13 v1.14.1 1.14.0 v1.13 <error> 1.14.1-dev v1.13 v1.14.1 1.15.0-dev v1.14 <error> 1.13.90 v1.12 v1.13.89 <-- decremented 2.0.1 <error> v2.0.0 <-- decremented Fixes: 5581963 ("ci/ipsec: Fix version retrieval for downgrades to closest patch release") Signed-off-by: Quentin Monnet <quentin@isovalent.com>
70cc79a
to
73ab19a
Compare
/test-backport-1.13 Job 'Cilium-PR-K8s-1.19-kernel-4.19' failed: Click to show.Test Name
Failure Output
Jenkins URL: https://jenkins.cilium.io/job/Cilium-PR-K8s-1.19-kernel-4.19/369/ If it is a flake and a GitHub issue doesn't already exist to track it, comment Then please upload the Jenkins artifacts to that issue. |
/test-1.19-4.19 |
test-1.19-4.19: hit #22749 |
test-1.26-net-next: vm provisioning failure |
/test-1.26-net-next |