Open jrhemstad opened 8 months ago
@jrhemstad I'm going to start looking at this this week.
About RC's, we could tag a new RC for each merge, but I'm not sure what this does for us. Seems like each RC will basically map to a SHA on the branch, and the RCs will have lost meaning.
Alternatively, we could manually invoke the Update RC workflow intentionally when we have a need for an RC (eg. the we have collected all of the planned backports and consider a particular SHA on the release branch to be ready-for-release. We could additionally make the tagging process dependent on a thorough set of test/benchmark results that validate the code before exposing the tag to users that may want to test the code before the full release.
Is this a duplicate?
Area
Infrastructure
Is your feature request related to a problem? Please describe.
As a maintainer of CCCL, I'd like to have an automated release process in line with the GitLab flow model, ensuring consistent and error-free releases.
Goals:
branch/X.Y.x
, frommain
.main
.vX.Y.0-rc0
, once the pull request is merged intomain
and backported to the release branch.vX.Y.0-rc1
, on the release branch upon merging backported changes.vX.Y.0
, and draft GitHub releases upon manual approval.Describe the solution you'd like
Proposed Actions:
Start Release Action (Manual Trigger)
new_version
: SemVer string (e.g., 2.3.0 for the release 2.3.0).branch/X.Y.x
.main
with the version changes.Update RC Action (Automatic Trigger)
branch/*
.Finalize Release Action (Manual Trigger)
release_version
: SemVer string of the final release version.branch_name
: The release branch name (e.g.,branch/X.Y.x
).vX.Y.Z
.Edge Cases & Additional Considerations:
Example: Starting a New Minor Release
Current Scenario:
main
branch is at version 2.2.0.Automated Steps:
new_version
input as2.3.0
.branch/2.3.x
frommain
.update_version.sh
script is run on a new branchupdate-version-2.3.0
, changing the version to 2.3.0 in the codebase.update-version-2.3.0
intomain
with abackport branch/2.3.x
label.branch/2.3.x
.branch/2.3.x
, the "Update RC Action" is triggered, and it tags the commit withv2.3.0-rc0
.If additional fixes are needed in 2.3.0:
main
and tagged with thebackport branch/2.3.x
label.branch/2.3.x
, the "Update RC Action" is triggered.branch/2.3.x
.v2.3.0-rc1
exists, it will createv2.3.0-rc2
).branch/2.3.x
with the new RC tag (e.g.,v2.3.0-rc2
).Finalizing the Release:
release_version
input as2.3.0
.branch/2.3.x
.v2.3.0
).v2.3.0
tag, with the pre-filled release notes for the maintainer to review.Example: Creating a Hotfix Release Candidate
Current Scenario:
v2.3.0
is out.Automated Steps:
main
and the PR is merged intomain
.backport branch/2.3.x
label is added to the PR.branch/2.3.x
.branch/2.3.x
, the "Update RC Action" automatically identifies thatv2.3.0
is the latest non-RC tag.v2.3.1-rc0
.