// Use when decommissioning an end-of-life RHDH release branch by removing CI config, generated Prow jobs, and branch protection from the openshift/release repository
Check AKS Kubernetes version support status using the official AKS release status API and compare against versions configured in CI config files. Use whenever someone asks about AKS K8s version support, EOL dates, deprecation, or whether the configured AKS version is still GA. Also use when planning AKS K8s version upgrades — run this before using rhdh-aks-tests to make changes.
List AKS test entries in RHDH ci-operator config files and update the AKS Kubernetes version per branch. Use when listing e2e-aks tests, changing MAPT_KUBERNETES_VERSION for AKS, or checking which AKS K8s version each release branch uses.
Check EKS Kubernetes version support status using the official AWS EKS docs source and compare against versions configured in CI config files. Use whenever someone asks about EKS K8s version support, EOL dates, or whether the configured EKS version is still in standard support. Also use when planning EKS K8s version upgrades — run this before using rhdh-eks-tests to make changes.
List EKS test entries in RHDH ci-operator config files and update the EKS Kubernetes version per branch. Use when listing e2e-eks tests, changing MAPT_KUBERNETES_VERSION for EKS, or checking which EKS K8s version each release branch uses.
Check GKE Kubernetes version support status using the endoflife.date API (auto-scraped from Google's GKE release schedule). Use whenever someone asks about GKE K8s version support, EOL dates, or whether the current GKE cluster version is still supported. GKE uses a long-running static cluster whose version is not managed in CI config.
List GKE test entries in RHDH ci-operator config files. Use when listing e2e-gke tests or checking which branches have GKE test entries. Unlike AKS/EKS, GKE uses a pre-existing static cluster — version upgrades are performed via the GCP Console.
| name | rhdh-decommission-release |
| description | Use when decommissioning an end-of-life RHDH release branch by removing CI config, generated Prow jobs, and branch protection from the openshift/release repository |
| allowed-tools | Read, Edit, Bash(ls ci-operator/config/redhat-developer/rhdh/redhat-developer-rhdh-release-*), Bash(find ci-operator/config/redhat-developer/rhdh -name 'redhat-developer-rhdh-release-*'), Bash(rm ci-operator/config/redhat-developer/rhdh/redhat-developer-rhdh-release-*), Bash(rm ci-operator/jobs/redhat-developer/rhdh/redhat-developer-rhdh-release-*), AskUserQuestion |
You are helping the user decommission CI jobs for an end-of-life RHDH (Red Hat Developer Hub) release branch.
Decommissioning removes all CI configuration for a given RHDH release branch. This is done when a release reaches end-of-life and no longer needs CI jobs running. Based on the pattern from PR #71895.
Get the release version:
ls ci-operator/config/redhat-developer/rhdh/redhat-developer-rhdh-release-*.yamlVerify the files to be removed: Show the user what will be deleted and ask for confirmation:
ci-operator/config/redhat-developer/rhdh/redhat-developer-rhdh-release-{version}.yamlci-operator/jobs/redhat-developer/rhdh/redhat-developer-rhdh-release-{version}-*.yaml (typically -presubmits.yaml and -periodics.yaml)release-{version}: block in core-services/prow/02_config/redhat-developer/rhdh/_prowconfig.yamlIf the CI config file does not exist, warn the user that this release may have already been decommissioned and ask if they want to continue checking for leftover files.
Delete the CI config file:
Remove ci-operator/config/redhat-developer/rhdh/redhat-developer-rhdh-release-{version}.yaml
Delete the generated job files:
Remove all matching files: ci-operator/jobs/redhat-developer/rhdh/redhat-developer-rhdh-release-{version}-*.yaml
Remove branch protection configuration:
Edit core-services/prow/02_config/redhat-developer/rhdh/_prowconfig.yaml to remove the entire release-{version}: block under branch-protection.orgs.redhat-developer.repos.rhdh.branches.
The block to remove looks like:
release-{version}:
allow_deletions: false
allow_force_pushes: false
enforce_admins: true
protect: true
required_status_checks:
contexts:
- <context1>
- <context2>
- <context3>
Be careful to:
Confirm completion: Summarize what was removed:
make update -- since we are only deleting files and removing branch protection, there is nothing to regenerateci-operator/jobs/ are normally auto-generated, but when decommissioning we simply delete them along with the source config