/flux-controller-minor-releases

name: flux-controller-minor-releases
description: >
  Run the upstream Flux controller minor release procedure for helm-controller,
  image-automation-controller, image-reflector-controller, kustomize-controller,
  notification-controller, source-controller, and source-watcher. Use when
  cutting a new controller minor release (vX.Y.0): creating the release series
  branch, drafting the minor changelog, tagging, merging the release branch back
  to main, and adding the backport label.
license: Apache-2.0

Flux Controller Minor Releases

Use this skill for upstream Flux controller **minor** releases (`vX.Y.0`) only — the release that opens a new `release/vX.Y.x` series. Do not use it for `flux2`, `pkg`, or other non-controller repos.

Supported controllers:

• `helm-controller`
• `image-automation-controller`
• `image-reflector-controller`
• `kustomize-controller`
• `notification-controller`
• `source-controller`
• `source-watcher`

Important rules

• **Strictly follow the documented git commands, one step at a time.** Each step

below has a reason. Do not invent substitutions, batch unrelated commands into one shell invocation, or insert extra verification commands between documented steps unless asked. Adapt only the version numbers.

• **Never block the conversation on long-running operations.** CI checks, the

tag-triggered release workflow, and approval waits must be watched in the background (`run_in_background`) so the user can keep steering and you get notified on completion. A foreground watch blocks the session.

• **Always quote PR/issue links as full URLs** (e.g.

`https://github.com/fluxcd/source-controller/pull/2082`), never the `<owner>/<repo>#<number>` shorthand — full URLs are clickable from the user's terminal.

• **Start background watches on every PR immediately after opening it.** Kick off

`gh pr checks <num> -R fluxcd/<repo> --watch` in the background as soon as the PR is created, and the same for tag-triggered release workflows (`gh run watch <id> -R fluxcd/<repo>`).

• **Also start a background approval watch per PR.** `gh pr checks --watch` only

covers CI, not maintainer approval. Poll the review state in the background:

  while :; do
    state=$(gh pr view <num> -R fluxcd/<repo> --json mergeStateStatus,reviewDecision --jq '.reviewDecision+" "+.mergeStateStatus')
    case "$state" in "APPROVED CLEAN") echo "$state"; break;; esac
    sleep 30
  done

• Every git commit must use `-s` (sign-off). Never include Co-Authored-By lines,

your own name, or any AI attribution in commit messages, PR titles, or PR descriptions. This applies to the skill-update PR too.

• Always wait for CI to go green before merging any PR.
• You cannot approve your own PRs. If a PR was opened by the git user driving the

session, ask a maintainer to approve it (or confirm it is already approved) before merging.

• **Merge release PRs yourself** as soon as CI is green **and** a maintainer has

approved — act immediately so the next step (tag push, merge to main, label PR) unblocks. Applies only to PRs opened with the user's account this session.

• **Review feedback on the release PR is applied by amending**, not by adding new

commits. The release PR must stay at exactly two commits (`Add changelog entry for vX.Y.0` and `Release vX.Y.0`). Use `git reset --soft HEAD~2` + re-commit, or an interactive rebase, then `git push --force-with-lease`.

• **After applying a review fix, reply `Fixed, thanks!` on the thread and resolve

it.** Reply via `gh api repos/<owner>/<repo>/pulls/<n>/comments/<cid>/replies -f body='Fixed, thanks!'` and resolve via the GraphQL `resolveReviewThread` mutation.

• Tags must be annotated and signed (`git tag -s -m ...`). Never create release

tags through the GitHub API — that produces lightweight tags which break `git tag -v` verification.

• **PR titles and bodies.** Release-prep and label PRs use the commit subject as

the title. The release→main PR uses the GitHub-default humanized branch name `Release/vX.Y.x`. Every PR body is a single line pointing at the flux2 minor release tracking issue: `Part of: https://github.com/fluxcd/flux2/issues/NNNN`.

• **Do not declare the release done until every step below has run**, including

the final backport label PR (step 11). Tagging and merging to main are not the last step. Walk the numbered steps and confirm each one ran before reporting completion.

Preconditions

• Read the upstream procedure at `website/content/en/flux/releases/procedure.md`,

section `Controllers: minor releases` (https://fluxcd.io/flux/releases/procedure/#controllers-minor-releases).

• Identify the flux2 minor-release tracking issue so PR bodies can reference it

(`Part of: https://github.com/fluxcd/flux2/issues/NNNN`).

• Use `date` to get the release date for the changelog entry.
• `git fetch --all --tags --prune` before reasoning about branches, tags, or

merged PRs. Do not trust stale local `origin/*` refs.

• Treat `git` and `gh` commands as confirmation points if the user wants that.

Release Flow

For the controller being released (target version `vX.Y.0`):

1. Create the release series branch from `main` and push it.

• `git switch -c release/vX.Y.x main`
• `git push origin release/vX.Y.x`

2. Create the release preparation branch from the series branch.

• `git switch -c release-vX.Y.0 release/vX.Y.x`

3. Draft the new `CHANGELOG.md` entry (see "How To Build The Changelog Entry"). Then commit it.

• `git add CHANGELOG.md`
• `git commit -s -m "Add changelog entry for vX.Y.0"`

4. Apply the release version bump exactly as documented.

• Update the controller self-API version in the root `go.mod` to `vX.Y.0`.

Inspect the actual `go.mod`; do not assume the self-API path form (`source-watcher` uses `github.com/fluxcd/source-watcher/api/v2`).

• Update `config/manager/kustomization.yaml` `newTag` to `vX.Y.0`.
• `git add go.mod config/manag