cut-new-release-candidate

name

cut-new-release-candidate

description

Trigger a new release candidate build from a user-provided release branch name. Use when the user asks to cut/trigger/start a new release candidate (e.g. “cut a new RC”, “trigger Cut New Release Candidate”, “make a new .stable_01/.preview_01”) and provides (or can provide) the release branch. Runs the GitHub Actions workflow “Cut New Release Candidate” on the specified ref and returns the run URL (does not wait for completion). Also posts an update to Slack after triggering.

cut-new-release-candidate

Trigger the release-candidate workflow ($RC_WORKFLOW_NAME) GitHub Action on a specified release branch ref and return the workflow run URL.

Configuration

This skill reads environment-specific values from environment variables (see the repo README.md):

• INTERNAL_REPO — owner/repo that holds your release branches and the workflow.
• REPO_DIR — absolute path to your local checkout of INTERNAL_REPO.
• RC_WORKFLOW_NAME — name of the GitHub Actions workflow that cuts a release candidate (default Cut New Release Candidate).
• RELEASE_CHANNELS — space-separated release channels used to recognize release branches (default preview stable).
• RELEASE_BRANCH_PREFIX — per-channel branch path prefix; {channel} is replaced with the channel name (default {channel}_release/).

All git/gh operations run inside INTERNAL_REPO.

Step 1: Clarify inputs

Ensure you have:

• Release branch name (required), e.g. stable_release/v0.YYYY.MM.DD.HH.MM.stable_NN

If the user provides origin/<branch>, strip the origin/ prefix.

Reject non-release branches: the branch must start with the configured RELEASE_BRANCH_PREFIX for one of $RELEASE_CHANNELS:

is_release=0
for ch in $RELEASE_CHANNELS; do
  prefix=$(printf '%s' "$RELEASE_BRANCH_PREFIX" | sed "s|{channel}|$ch|")
  case "$BRANCH_NAME" in
    "$prefix"*) is_release=1; break;;
  esac
done
[ "$is_release" = 1 ] || { echo "Not a release branch: $BRANCH_NAME"; exit 1; }

Step 2: Ensure repo context

If you are not already in the release repo:

• Try cd "$REPO_DIR"
• If REPO_DIR is unset or the path does not exist, ask the user for the local path to their release repo, then cd there

Step 3: Validate the branch exists on origin

BRANCH_NAME="<release_branch>"

git fetch origin
git ls-remote --exit-code --heads origin "$BRANCH_NAME" >/dev/null

If this fails, tell the user the branch was not found on origin and ask them to confirm the exact branch name.

Step 4: Trigger the workflow

Trigger the workflow by name on the provided ref:

gh workflow run "$RC_WORKFLOW_NAME" \
  --repo "$INTERNAL_REPO" \
  --ref "$BRANCH_NAME"

Step 5: Return the run URL (no waiting)

Fetch the newest run for this workflow on the branch and return its URL:

gh run list \
  --repo "$INTERNAL_REPO" \
  --workflow "$RC_WORKFLOW_NAME" \
  --branch "$BRANCH_NAME" \
  --limit 1 \
  --json url,status,conclusion,createdAt \
  --jq '.[0]'

Share the url with the user. Do not watch/wait for completion.

Step 6: Post an update to Slack

After triggering, post an update to Slack with the branch name and the run URL.

• If the user provides a Slack channel and thread to reply in, invoke the respond-to-slack-thread skill to post the update.
• Otherwise, ask the user where to post (channel + optional thread link) and what audience they want notified.

Suggested message text (edit as needed):

Triggered *$RC_WORKFLOW_NAME* for `$BRANCH_NAME`.
Run: <RUN_URL>

Notes

• This workflow infers the channel from the branch name (via RELEASE_BRANCH_PREFIX), so it must be run on a release branch.
• If gh auth fails, ask the user to authenticate (gh auth status / gh auth login) and retry.