rhdh-prow-release-branch

Name: rhdh-prow-release-branch
Author: redhat-developer

github.com/redhat-developerCloud & DevOps1945 installsUpdated 1d ago

About rhdh-prow-release-branch

A skill for enabling or removing Prow CI configuration for a `redhat-developer/rhdh` release branch. It guides local configuration changes and generated job updates, while requiring confirmation of version-specific settings and gated publication.

Key features

01Commission release-branch CI
02Decommission end-of-life branch CI
03Update configuration with make update
04Validate release-specific settings
05Gate commits, pushes, and pull requests

Use cases

01Set up CI for a new release branch
02Remove CI for an end-of-life branch
03Review generated Prow job files
04Plan rollback before destructive removal

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/redhat-developer/rhdh-skills --skill rhdh-prow-release-branch

After installing, type/rhdh-prow-release-branchin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

agents/

openai.yaml

references/

release-branch-config.md

workflows/

commission-release.md

decommission-release.md

Details

From the project README

RHDH release-branch Prow configuration

Turn the CI configuration for one release-{version} branch of redhat-developer/rhdh on or off in openshift/release. Both directions need a local checkout because both end in make update.

This skill is about Prow configuration, not about the product release. What is open against a release is /rhdh-release-status, its milestone dates are /rhdh-release-schedule, and its freeze announcement is /rhdh-release-announce. Individual test entries and cluster pools on a branch that already has jobs belong to /rhdh-prow-jobs.

Route

Intent	Load
Create CI configuration for a new release branch	`workflows/commission-release.md`
Remove CI configuration for an end-of-life release branch	`workflows/decommission-release.md`

references/release-branch-config.md holds the file paths, the release-vs-main differences, and the Slack alert setup that both workflows use. Read it with whichever workflow you loaded.

Local preparation and publication

Creating the local review branch, copying or deleting the config, editing _prowconfig.yaml, and running make update are local preparation authorized by the user's commission or decommission request. Make and validate those local changes without a write gate.

Follow /mutation-gate for commit, push, and pull request creation only. Treat them as one ordered publication set, name every reviewed path and external target, and stop before each later operation when an earlier one fails.

Never hardcode the branch-protection block or the release-branch adjustments. Read the latest existing release branch and copy its current shape; required status-check contexts and presubmit settings change over time.
Confirm the version-specific values with the user before finalizing: which OCP test entries to include, MAPT_KUBERNETES_VERSION, the OSD version, releases.latest.release, and the build_root tag.
Decommissioning is destructive. Name every file and block to be removed, and the rollback, before removing anything.
The Slack channel, its incoming webhook, and the Vault key SLACK_ALERTS_WEBHOOK_URL_{X}_{Y} are human steps outside the repository. Ask the user to perform them; do not treat the config change as finished while reporter_config.channel points at a channel that does not exist.

Completion

Commissioning is complete when ci-operator/config/redhat-developer/rhdh/redhat-developer-rhdh-release-{version}.yaml exists with zz_generated_metadata.branch set to release-{version}, the release-branch adjustments from the reference have been applied, the release-{version} branch-protection entry sits in version order in _prowconfig.yaml, make update has run, and the generated ci-operator/jobs/redhat-developer/rhdh/redhat-developer-rhdh-release-{version}-*.yaml files are listed by name. State the Slack channel and Vault key status, and note that the jobs will not fire until the release-{version} branch itself exists in redhat-developer/rhdh.

Decommissioning is complete when the config file is deleted, the release-{version} block is gone from _prowconfig.yaml with surrounding indentation intact, make update has removed the generated job files, and every removed file and block is named alongside its rollback. In both directions, state the push and pull-request state explicitly — including "not pushed".

Comments

Markdown supported

Details

Author: redhat-developer
Repository: redhat-developer/rhdh-skills
Category: Cloud & DevOps
Installs: 45
GitHub stars: 19

Report

More skills

All skills

lark-apps

open.feishu.cn

732.0k

Develop and host Miaoda (Spark/Miaoda) apps: app creation, local full-stack development, cloud generation and iteration, creative design (UI mockups / interactive prototypes / wireframes / landing pages / dashboards / slide decks / visual exploration), integration of AI-related capabilities, Feishu platform capabilities, or other external capabilities; log/Trace/monitoring metric/PV/UV queries; environment variable management; app collaborators and collaboration permissions; app roles and members; and automation triggers (scheduled / record changes / Webhook / Feishu approvals). Use when users want to develop or create a system, tool, platform, or app; develop locally or in the cloud, modify, deploy, publish, launch, or get a shareable link; create a page or website with HTML and deploy it to Miaoda; design, create a mockup, prototype, wireframe, PPT, deck, or visual exploration; or mention Miaoda/Spark/Miaoda apps (links like `/app/app_xxx` or `/page/<token>`, runtime domains like *.aiforce.cloud), app databases, app file storage, open API Keys, visibility, app collaborators/developer permissions, app roles/role members, production logs, API request volume, error volume, latency, traffic, environment variables, or setting up automation tasks, scheduled triggers, or approval-triggered automation for Miaoda apps. Not for regular cloud drive file uploads (lark-drive), Feishu document editing (lark-doc), or native slide creation (lark-slides).

azure-prepare

github.com/microsoft

571.7k

Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.

wizard

github.com/mattpocock

571.5k

Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.

azure-ai

github.com/microsoft

571.2k

Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.