- approval gate now honors latest review state per reviewer; a reviewer
who later submits CHANGES_REQUESTED or has their approval dismissed no
longer counts as approved. Plain COMMENTED follow-ups don't override
an existing approval (matches GitHub's own behavior).
- success summary links to the tag's tree URL instead of /releases/tag/,
which would 404 because this workflow creates an annotated git tag,
not a GitHub Release object.
The workflow now does its own gating rather than trusting the operator
to pre-stage a clean candidate, and creates the version-bump commit
itself so the candidate branch can be a pure cherry-pick chain.
Operator flow (changed):
- Locally cherry-pick the backport commits onto the previous stable
tag. NO version-bump commit.
- Push the candidate branch and open a PR against `master`.
- Wait for CI green; get an APPROVED review from a user listed in the
repo variable `STABLE_RELEASE_APPROVERS`.
- Run the workflow with `source_branch` = candidate branch.
Workflow now verifies, in order:
1. `source_branch` matches a safe ref-name regex.
2. `STABLE_RELEASE_APPROVERS` repo variable is configured.
3. Latest stable tag = highest semver `vX.Y.Z`; next version is
`last_tag_patch + 1` (computed; no longer a workflow input).
4. Source branch exists on origin; target release branch and tag
do NOT exist (refuse to overwrite).
5. Branch is rooted at the latest stable tag:
* tag is an ancestor of source HEAD,
* `merge-base(source, master) == tag commit` (no master commits
sneaked in via merge/rebase),
* no merge commits in `tag..source` (linear cherry-picks only).
6. Version files on the candidate still equal the previous tag's
version (operator must NOT include a version bump). Read via
`git show | python3 -c '...'` so candidate code is never executed,
and `comfyui_version.py` is statically AST-parsed for `__version__`.
7. PR for the source branch exists, targets master, head SHA matches
the candidate, has an APPROVED review on that exact SHA from an
allow-listed user (stale approvals on older commits don't count),
and all check-runs / commit-statuses on the SHA are success /
neutral / skipped. `mergeable_state` is intentionally not used —
backport branches by definition aren't "up-to-date with master".
After all gates pass, the workflow creates the version-bump commit
itself (edits `pyproject.toml` + `comfyui_version.py` via stdlib regex,
commits as `github-actions[bot]`), then atomically pushes
`release/v<version>` + `v<version>` annotated tag using
`RELEASE_BOT_TOKEN`.
Kept from the previous revision: atomic ref push, `persist-credentials:
false` checkout, AST-based version-file parse (never `exec()`), all
inputs flow through `env:` vars (no command injection), `dry_run`
short-circuits the push step, pre-flight existence checks, step summary
linking to `release-stable-all.yml`.
Verified end-to-end against Kosinkadink/ComfyUI with sentinel `v0.99.99`
→ `v0.99.100`: dry-run passed all 11 steps; real run created
`release/v0.99.100` + `v0.99.100` atomically. Negative cases for the
approval gate and version-file gate also exercised.
- security: pass all inputs via env vars (no command injection)
- security: validate ref names against safe charset
- bug: use robust dry_run check (handle bool and 'true'/'false' string)
- robustness: combine branch+tag push into single atomic operation
- robustness: add set -euo pipefail to Configure git identity step
Amp-Thread-ID: https://ampcode.com/threads/T-019e042d-d972-7559-b462-6e838c2da164
Co-authored-by: Amp <amp@ampcode.com>
