Skip to content

OCP Branching Tasks

OCP Branching Tasks for the HyperShift Team

These are a set of tasks we need to perform on every OCP branching. We need to:

  1. Update the HyperShift Repository to add the latest supported OCP version - Update Supported Version
  2. Update the base images in our Dockerfiles (if they are available at branching) - Update Dockerfiles
  3. Update the Renovate configuration to include the new release branch - Update Renovate
  4. Update the GitHub Actions branch filters and verify the checks on the new release branch - Update GitHub Actions
  5. Update the OpenShift Release repository to fix the step registry configuration files - OpenShift/Release
  6. Update TestGrid to include the new OCP version tests - TestGrid
  7. Add upgrade-from-.0 periodic jobs for ROSA and ARO HCP once the new version is GA - Upgrade-from-.0 Periodics

Danger

If test platform are testing new OCP releases before the release is cut the hypershift test will fail and block payloads until:

  • There are at least two accepted nightly payloads for the new release.
  • The supported versions in the HyperShift repository are updated.

HyperShift Repository

Update Supported Version

We need to add the latest supported version in the hypershift repository. We need to modify two files:

  • support/supportedversion/version.go which contains the variable called LatestSupportedVersion. This one contains, as you can imagine, the Latest supported version. We need to put the new version here.
  • support/supportedversion/version_test.go contains the tests to validate the Latest version. It should comply with the established contract to support 2 versions prior to the Latest.

Example Supported Version Bump PR

Update Dockerfiles

We also need to bump the base images in our Dockerfiles.

Example Base Image Bump PR

Update Renovate Configuration

We need to add the new release branch to the Renovate configuration so that security updates are automatically applied to the release branch.

Update renovate.json to include the new release branch in two places:

  1. Add the new branch to the baseBranches array at the top of the file
  2. Add the new branch to the matchBaseBranches array in the security-only Go updates package rule

Note

If any release branch has reached End of Life and is no longer supported, remove it from both locations in renovate.json to stop automated updates on that branch.

Example change for release-4.21: 

{
  "baseBranches": [
    "main",
    "release-4.16",
    "release-4.17",
    "release-4.18",
    "release-4.19",
    "release-4.20",
    "release-4.21"
  ],
  "packageRules": [
    {
      "description": "Enable security-only Go updates on release branches",
      "matchManagers": ["gomod"],
      "matchBaseBranches": [
        "release-4.16",
        "release-4.17",
        "release-4.18",
        "release-4.19",
        "release-4.20",
        "release-4.21"
      ],
      "matchUpdateTypes": ["patch"]
    }
  ]
}

Update GitHub Actions Branch Filters

GitHub evaluates a pull_request workflow from the pull request's base branch. After cutting a release branch, first identify which GitHub Actions checks are intended to run for that release, then update those workflows on both main and the new release branch:

  1. Decide which checks should run for the new release branch. Do not automatically enable every workflow.
  2. Add the new branch to pull_request.branches in each selected caller workflow under .github/workflows/.
  3. Add the new branch to push.branches in the selected reusable workflows that run post-merge checks. Ensure the release branch contains the same intended job configuration so pull request and post-merge coverage do not diverge.
  4. Merge the update into the new release branch. The GitHub Actions checks do not run on this bootstrap pull request because its base branch does not contain the new filter yet.
  5. Synchronize an existing pull request against the release branch, or open a test pull request, and verify that only the expected GitHub Actions checks are reported.

For release-5.0, only the OCP and vanilla Kubernetes envtests are enabled. Add the branch to envtest-ocp.yaml, envtest-kube.yaml, and the matching reusable workflows. The release-branch reusable workflows must also include the Kubernetes 1.36 matrix entries from main before enabling their post-merge triggers.

For example:

on:
  pull_request:
    branches:
      - main
      - release-4.22
      - release-5.0

Use gh pr checks <pull-request-number> --repo openshift/hypershift to verify the pull request checks. To verify post-merge workflows, use gh run list --repo openshift/hypershift --event push --branch <release-branch>. Do not use the release branch with gh run list --event pull_request --branch; GitHub records pull request runs under the pull request's head branch.

Openshift/Release Repository

The Step registry config should be updated by Test Platform. However, the Test Platform is not aware of custom configurations of the different version for specific hypershift tests. So, we need to check over the Step registry config and make sure that the hypershift tests are correctly configured. Below is an example of the necessary changes to the Step registry config after test platform bumps:

Example Release Repo PR

We should also ensure that the latest release branch is using the Hypershift Operator and e2e from main. Specifically, the release branch CI config should import hypershift-tests as a pre-built base image from the hypershift namespace rather than building it from Dockerfile.e2e in the release branch source. This ensures the e2e binary comes from main and keeps release branch configs consistent. The changes needed are:

  1. Add hypershift-tests to the base_images section (namespace: hypershift, tag: latest)
  2. Remove the Dockerfile.e2e entry from the images section
  3. Remove hypershift-tests from the promotion exclusion list (since it is no longer built)

Example Release Branch PR (4.21)

Example Release Branch PR (4.22)

Update TestGrid

We need to update TestGrid to include the new OCP version tests.

Here is an Example PR to do that.

Add Upgrade-from-.0 Periodic Jobs

Once a new OCP minor version goes GA, we need to add upgrade-from-.0 periodic jobs for both AWS (ROSA) and Azure (ARO HCP) platforms in the openshift/release repository. These jobs validate that clusters can upgrade from CPO version 4.Y.0 to 4.Y.latest without triggering NodePool rollouts.

Jobs to create for each new GA version:

  • AWS (ROSA): periodic-ci-openshift-hypershift-release-4.Y-periodics-hcm-upgrade-dot-zero-to-latest-aws-ovn
  • Azure (ARO HCP): periodic-ci-openshift-hypershift-release-4.Y-periodics-hcm-upgrade-dot-zero-to-latest-azure

The CI operator configs live at:

  • ci-operator/config/openshift/hypershift/openshift-hypershift-release-4.Y__periodics-hcm-upgrade.yaml (AWS)
  • ci-operator/config/openshift/hypershift/openshift-hypershift-release-4.Y__periodics-hcm-azure.yaml (Azure)

Use the existing job configurations from the prior OCP version as a template. Both jobs run the TestUpgradeControlPlane test with PREVIOUS_RELEASE_IMAGE set to 4.Y.0 and LATEST_RELEASE_IMAGE set to 4.Y.latest.

For detailed requirements and job specifications, see: