[FEA]: Automate release process

[jrhemstad]

Is this a duplicate?

• I confirmed there appear to be no duplicate issues for this request and that I agree to the Code of Conduct

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:

1. Automate the creation of release branches, branch/X.Y.x, from main.
2. Update the version in code via scripts and create a pull request with these changes against main.
3. Tag the repository with an initial RC tag, vX.Y.0-rc0, once the pull request is merged into main and backported to the release branch.
4. Automatically generate incremental RC tags, vX.Y.0-rc1, on the release branch upon merging backported changes.
5. Create final release tags, vX.Y.0, and draft GitHub releases upon manual approval.

Describe the solution you'd like

Proposed Actions:

1. Start Release Action (Manual Trigger)

   • Inputs:
     • new_version: SemVer string (e.g., 2.3.0 for the release 2.3.0).
   • Behavior:
     • Creates a new release branch named branch/X.Y.x.
     • Runs a script to update version numbers in the codebase.
     • Opens a PR against main with the version changes.

2. Update RC Action (Automatic Trigger)

   • Triggers:
     • On merge commits to branch/*.
   • Behavior:
     • If an RC tag does not exist, it implies this is the first backport to the release branch for the current version, and the vX.Y.0-rc0 tag is created.
     • Checks if a final tag for the current version exists.
     • If so, identifies the latest patch version tag and creates a new RC tag for the next patch version.
     • If not, increments the RC number and creates a new tag.

3. Finalize Release Action (Manual Trigger)

   • Inputs:
     • release_version: SemVer string of the final release version.
     • branch_name: The release branch name (e.g., branch/X.Y.x).
   • Behavior:
     • Creates a new tag vX.Y.Z.
     • Creates a draft GitHub release associated with the tag.
     • Creates and uploads release artifacts of cmake install as per [FEA]: SHA Stable release URLs #622

Edge Cases & Additional Considerations:

• The action scripts must handle the scenario where a release is finalized, and subsequent commits are made to the release branch, which should start a new patch version.
• The initial RC tag for a new minor/major version must be created correctly when there are no prior RC tags for the version.

Example: Starting a New Minor Release

Current Scenario:

• main branch is at version 2.2.0.
• We plan to start a new minor release 2.3.0.

Automated Steps:

1. A maintainer triggers the "Start Release Action" with new_version input as 2.3.0.
2. The action creates a new branch branch/2.3.x from main.
3. The update_version.sh script is run on a new branch update-version-2.3.0, changing the version to 2.3.0 in the codebase.
4. A PR is created to merge update-version-2.3.0 into main with a backport branch/2.3.x label.
5. Upon merge, our backport automation picks up the changes and creates a backport PR against branch/2.3.x.
6. Once the backport PR is merged into branch/2.3.x, the "Update RC Action" is triggered, and it tags the commit with v2.3.0-rc0.

If additional fixes are needed in 2.3.0:

1. Additional fixes are merged into main and tagged with the backport branch/2.3.x label.
2. For each subsequent merge that is backported to branch/2.3.x, the "Update RC Action" is triggered.
3. This action will:
   • Check the most recent RC tag on branch/2.3.x.
   • Increment the RC number based on the most recent tag (e.g., if v2.3.0-rc1 exists, it will create v2.3.0-rc2).
   • Tag the new commit in branch/2.3.x with the new RC tag (e.g., v2.3.0-rc2).

Finalizing the Release:

1. Once the release is ready to be finalized (all RCs are stable, and no further changes are required for the release):
   • A maintainer triggers the "Finalize Release Action" with the release_version input as 2.3.0.
   • The action checks out branch/2.3.x.
   • It tags the latest commit in the release branch with the final release version tag (e.g., v2.3.0).
   • The action then creates a draft GitHub release tied to the v2.3.0 tag, with the pre-filled release notes for the maintainer to review.
   • The draft release can then be published manually by the maintainer after final review and approval.

Example: Creating a Hotfix Release Candidate

Current Scenario:

• The latest release v2.3.0 is out.
• A critical bug is identified that needs a hotfix.

Automated Steps:

1. The bug is fixed in a new branch branched off main and the PR is merged into main.
2. A backport branch/2.3.x label is added to the PR.
3. The backport automation creates a new backport PR to merge these changes into branch/2.3.x.
4. After the backport PR is merged into branch/2.3.x, the "Update RC Action" automatically identifies that v2.3.0 is the latest non-RC tag.
5. The action increments the patch version and creates a new RC tag v2.3.1-rc0.

Tasks

Beta Give feedback

1. Initial version of "New Release" workflow
2. Initial version of "Update RC" workflow
3. Initial version of "Finalize Release" workflow
4. Change "New Release" workflow to bump version in topic branch on main + backport
5. Add final RC tag to final release workflow inputs as a validation check.
6. Generate installation tarball + zip
7. [FEA]: SHA Stable release URLs #622
   feature request needs triage +2
8. Create Draft Release
9. Update RC workflow to get version info from repo files. Error if release tag already exists (need to merge PR)
10. Immediately commit new version on release branch, make new main version an optional string input.
11. Slack notifications for RC acceptance / tagging

[alliepiper]

@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.