[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

• Initial version of "New Release" workflow #2915
• Initial version of "Update RC" workflow #2916
• Initial version of "Finalize Release" workflow #2917
• Change "New Release" workflow to bump version in topic branch on main + backport
• Add final RC tag to final release workflow inputs as a validation check.
• Generate installation tarball + zip
• [FEA]: SHA Stable release URLs #622
• Create Draft Release
• Update RC workflow to get version info from repo files. Error if release tag already exists (need to merge PR)
• Immediately commit new version on release branch, make new main version an optional string input.
• Update release finalization action to also kick-off CI testing from the release artifacts
• 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.