HO/CPO Release process

Important

This is a complex process that involves some changes in multiple repositories and will affect multiple teams daily basis work. Make sure you have multiple reviewers from Core dev team which could guide you in the full process.

Preparing a release in Openshift/Hypershift repository

Bumping release version and generating Release Notes

The hypershift repo produces two different artifacts: Hypershift Operator (HO) and Control Plane Operator (CPO).

The CPO release lifecycle is dictated by the OCP release payload.

The HO has an independent release cadence. For consumer products:

Our internal image build system builds from our latest commit in main several times a day.
To roll out a new build we apply the following process:

Automated flow (recommended)

The release process is managed via GitHub Actions workflows triggered by changes to releases/tags.yaml.

Request a tag: Open a PR adding an entry to releases/tags.yaml:

tags:
  - name: "v0.1.47"
    commit: "abc123def456789..."  # Full 40-char SHA from main
    description: "HO release for ROSA 4.17.8 rollout"

Validation: The validate-tag-request workflow automatically validates:
- Tag name is valid semver (v<major>.<minor>.<patch>)
- Commit SHA exists and is reachable from main
- Tag does not already exist
- No duplicate tag names in the manifest
Tag creation: Once the PR is reviewed and merged, the create-tag workflow creates an annotated git tag at the specified commit and pushes it.
Draft release: The tag push triggers create-release, which:
- Generates release notes from conventional commit messages using git-cliff
- Builds a source tarball with SHA256 checksum
- Creates a draft GitHub Release

Rehearsing workflow changes

The release workflows use reusable workflow files pinned to @main. Because GitHub Actions resolves reusable workflows from the default branch, changes to workflow YAML cannot be tested via normal PR CI.

A dedicated Rehearse Release Workflows (rehearse-release-workflows.yaml) workflow exists to solve this. It inlines the same install and validation steps so they run from the branch code. There are two ways to trigger it:

Automatic — push to a branch named fix/release-workflow-* that modifies any *release* or *tag* workflow file:

git checkout -b fix/release-workflow-my-change
# ... edit workflow files ...
git push origin fix/release-workflow-my-change
# The rehearsal workflow triggers automatically and results appear in the Actions tab.

Manual — once the rehearsal workflow exists on main, trigger it on any branch:

gh workflow run rehearse-release-workflows.yaml --ref my-branch

The rehearsal is read-only (permissions: contents: read) — it installs tools, parses releases/tags.yaml, and generates sample release notes, but never creates tags or releases.

Legacy manual flow

For cases where the automated flow is not available:

Create a git tag for the commit belonging to the image to be rolled out:
- git co $commit-sha
- git tag v0.1.1
- Push against remote.
Generate release notes:
- FROM=v0.1.0 TO=v0.1.1 make release
- Use the output to create the PR for bump the new image in the product gitOps repo. E.g.

Release notes sample

This is a sample of how the release notes looks like added to the PR:

## area/control-plane-operator

- [cpo: cno: follow image name change in release payload](https://github.com/openshift/hypershift/pull/2230)

## area/hypershift-operator

- [Added documentation around supported-versions configmap](https://github.com/openshift/hypershift/pull/2220)
- [Add comment for BaseDomainPrefix](https://github.com/openshift/hypershift/pull/2219)
- [Add condition to NodePool indicating whether a security group for it is available](https://github.com/openshift/hypershift/pull/2216)
- [HOSTEDCP-827: Add root volume encryption e2e test](https://github.com/openshift/hypershift/pull/2192)
- [fix(hypershift): reduce CAPI rbac access](https://github.com/openshift/hypershift/pull/2173)
- [Validate Network Input for HostedCluster](https://github.com/openshift/hypershift/pull/2215)