- 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>
* Add Spectral lint CI gate for openapi.yaml
Adds a blocking Spectral lint check that runs on PRs touching
openapi.yaml or the ruleset itself. The ruleset mirrors the one used
for other Comfy-Org service specs: spectral:oas plus conventions for
snake_case properties, camelCase operationIds, and response/schema
shape. Gate runs at --fail-severity=error, which the spec currently
passes with zero errors (a small number of non-blocking
warnings/hints remain for WebSocket 101 responses, the existing loose
error schema, and two snake_case wire fields).
* ci: set least-privilege contents:read permissions on openapi-lint workflow
Per CodeRabbit review on #13410. The job only checks out the repo and
runs Spectral, so contents:read is sufficient and avoids inheriting any
permissive repo/org default token scope.
---------
Co-authored-by: guill <jacob.e.segal@gmail.com>
Fires on v* tag push (earlier than release.published, which can lag)
and triggers a repository_dispatch on Comfy-Org/cloud with event_type
comfyui_tag_pushed. Legacy desktop dispatch in release-webhook.yml
is left untouched.
Add a GitHub Actions workflow and shell script that scan all commits
in a pull request for Co-authored-by trailers from known AI coding
agents (Claude, Cursor, Copilot, Codex, Aider, Devin, Gemini, Jules,
Windsurf, Cline, Amazon Q, Continue, OpenCode, etc.).
The check fails with clear instructions on how to remove the trailers
via interactive rebase.
* feat: add CI container version bump automation
Adds a workflow that triggers on releases to create PRs in the
comfyui-ci-container repo, updating the ComfyUI version in the Dockerfile.
Supports both release events and manual workflow dispatch for testing.
* feat: add CI container version bump automation
Adds a workflow that triggers on releases to create PRs in the
comfyui-ci-container repo, updating the ComfyUI version in the Dockerfile.
Supports both release events and manual workflow dispatch for testing.
* ci: update CI container repository owner
* refactor: rename `update-ci-container.yaml` workflow to `update-ci-container.yml`
* Remove post-merge instructions from the CI container update workflow.
* Fix showing progress from other sessions
Because `client_id` was missing from ths `progress_state` message, it
was being sent to all connected sessions. This technically meant that if
someone had a graph with the same nodes, they would see the progress
updates for others.
Also added a test to prevent reoccurance and moved the tests around to
make CI easier to hook up.
* Fix CI issues related to timing-sensitive tests
The checkbox for confirming custom node testing is now optional in both bug report and user support templates. This allows users to submit issues even if they haven't been able to test with custom nodes disabled, making the reporting process more accessible.
