mirror of
https://github.com/comfyanonymous/ComfyUI.git
synced 2026-05-30 10:57:23 +08:00
8626a290c4
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.
|
||
|---|---|---|
| .. | ||
| api-node-template.yml | ||
| check-ai-co-authors.yml | ||
| check-line-endings.yml | ||
| cut-release.yml | ||
| openapi-lint.yml | ||
| pullrequest-ci-run.yml | ||
| release-stable-all.yml | ||
| release-webhook.yml | ||
| ruff.yml | ||
| stable-release.yml | ||
| stale-issues.yml | ||
| tag-dispatch-cloud.yml | ||
| test-build.yml | ||
| test-ci.yml | ||
| test-execution.yml | ||
| test-launch.yml | ||
| test-unit.yml | ||
| update-api-stubs.yml | ||
| update-ci-container.yml | ||
| update-version.yml | ||
| windows_release_dependencies_manual.yml | ||
| windows_release_dependencies.yml | ||
| windows_release_nightly_pytorch.yml | ||
| windows_release_package.yml | ||