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
contrib: Support prereleases in release prep scripts #17502
contrib: Support prereleases in release prep scripts #17502
Conversation
5107ecf
to
44c38e0
Compare
I've been testing these out to generate #17501 with a standard Cilium release process by just specifying the RC tag version. Will leave at draft until we go through the full process to see if there are missing pieces. |
These changes will currently support preparing a vX.Y.0-rc0 release, but if we run it for vX.Y.0-rc1 then it will perform a diff between the latest vX.Y-1 series release rather than putting together a changelog for the vX.Y.0-rc0..vX.Y.0-rc1 changes. |
44c38e0
to
93a244a
Compare
I tested the first commit using instructions similar to those now updated in the .github issue template commit, and prepared v1.11.0-rc0 using those changes. The middle patches I just put together and I've done some initial testing locally to see whether they do roughly the correct thing, but we'll need to go through the -rc1 process to make sure that they work as intended all the way through. The issue template / docs updates, I've just assembled after the process so I think they capture everything that is needed but for those we would also need to follow the release process once more based on these instructions to iron out any bugs or missing steps. |
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.
Looks good as far as I can tell, with two minor comments you may feel free to ignore.
The git-foo and regexp magic in these files, plus my lack of experience on the release process, make any change rather hard to follow. I didn't see anything concerning, but in the end I'm mostly relying on your tests and experiments. (Nice to have some of the regexp handling factored under common.sh though.)
tail -n+4 $CHANGELOG >> $SUMMARY | ||
if [ "$BRANCH" = "master" ]; then | ||
echo "" >> $SUMMARY | ||
echo "See the included CHANGELOG.md for a full list of changes." >> $SUMMARY |
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.
FWIW I set this like this because RCs almost always have a changelog too big for the GH issue template. It'd be nice to have a more robust way to detect this for the .0 release as well since we'll include full changelog there as well I think, but 🤷 this is good enough for now.
Add support for vX.Y.0-rcN and vX.Y.0-snapshotN prereleases into the start-release.sh, submit-release.sh and tag-release.sh scripts. Signed-off-by: Joe Stringer <joe@cilium.io>
Move all of the version regex handling for releases into the common library script and reuse them from the release scripts. Signed-off-by: Joe Stringer <joe@cilium.io>
Previously, we would try to fetch the most recent branch in the tree and then use the version number in the most recent branch to understand which was the most recent micro release. When preparing -rc0 for the new release series, this would work correctly - for instance picking out 1.10 branch and finding the most recent 1.10.4 release from that branch. But it did not work for -rc1. Fix this by relying on the version-sorted list of tags from the upstream remote repository and picking out the semantically most recent one. If we're preparing a snapshot, it'll just try to pick up the most semantically recent tagged version. If we're preparing an RC, then start from either the most recent proper micro release or the most recent RC. Signed-off-by: Joe Stringer <joe@cilium.io>
The instructions for release candidate releases are slightly adjusted from a regular release. Add them into the main template that we use for most releases, now that the scripts have been updated to support this release type. These steps also largely apply the same way for a release with the format "vX.Y.Z-snapshotN". Signed-off-by: Joe Stringer <joe@cilium.io>
These instructions are updated based on the latest changes to the scripts to support release candidates, as well as the improvements to Helm chart sanity checking that we now have via GH workflows on the charts repository. Signed-off-by: Joe Stringer <joe@cilium.io>
96a51f5
to
4de69ae
Compare
Travis failed due to ratelimit, but it wasn't testing anything in this PR. There's only contrib/ and docs changes, and docs tests passed. Good to merge. |
Add support for vX.Y.0-rcN and vX.Y.0-snapshotN prereleases into the
start-release.sh and submit-release.sh scripts.