mirror of
https://github.com/Comfy-Org/ComfyUI_frontend.git
synced 2026-07-09 08:38:13 +00:00
747f76db76
## Problem `pr-backport.yaml` opens each backport PR (labelled `backport`) and calls `gh pr merge --auto --squash`. GitHub's `--auto` only takes effect when the repository's **"Allow auto-merge"** setting is enabled — it's currently off, so that call is a silent no-op (swallowed by its `|| echo "::warning::…"`). The result: every backport PR sits unmerged until someone manually clicks merge, even when it's already approved with green checks. ## What this does Adds `.github/workflows/backport-auto-merge.yaml`, which completes the merge directly — a plain `gh pr merge --squash` (which does **not** depend on the "Allow auto-merge" setting) — once GitHub reports the PR ready to merge. Ready = `reviewDecision == APPROVED` **and** `mergeStateStatus` is `CLEAN` or `UNSTABLE`. `UNSTABLE` means the required checks passed but a *non-required* check is still pending/failing — GitHub still permits that merge, and gating on `CLEAN` alone would leave backports stuck behind slow/flaky non-required checks (Socket, codecov, perf, storybook, etc.). **Branch protection stays the real gate.** The `core/**` / `cloud/**` ruleset unconditionally requires an approval + the required checks and can't be bypassed, and GitHub's merge API re-enforces it at merge time — so this workflow can only ever finish a merge that already satisfies those rules. The eligibility check just avoids pointless attempts. ## Design notes - **Merges with `PR_GH_TOKEN`, not the default token**, on purpose: a merge by the default `GITHUB_TOKEN` does not emit the `pull_request: closed` event, which would silently starve `cloud-backport-tag.yaml` (it creates the `cloud/vX.Y.Z` tag on that event). - **Triggers:** review submission + check-suite completion (low latency), plus a 30-min sweep as a backstop for cases the events miss. - **Never checks out PR code** (no untrusted-code path); only reads PR metadata via the API. `permissions` on the default token are read-only. - **Idempotent, bounded merge loop:** treats an already-merged PR (e.g. a concurrent run or a human) as success, so it won't post a false failure comment. - Leaves the existing conflict path in `pr-backport.yaml` untouched (conflicts never create a PR, so there's nothing here to act on). ## Validation YAML parses; `actionlint` (with shellcheck) and `zizmor` both clean (0 findings). ## Before relying on it - Confirm the org allows this workflow to run/merge (Actions policy) — the merge uses a PAT so it shouldn't depend on the "Actions can approve PRs" toggle, but worth verifying. - First real backport: confirm it merges on ready and that `cloud-backport-tag.yaml` then fires and creates the tag.
GitHub Workflows
Naming Convention
Workflow files follow a consistent naming pattern: <prefix>-<descriptive-name>.yaml
Category Prefixes
| Prefix | Purpose | Example |
|---|---|---|
ci- |
Testing, linting, validation | ci-tests-e2e.yaml |
release- |
Version management, publishing | release-version-bump.yaml |
pr- |
PR automation (triggered by labels) | pr-claude-review.yaml |
api- |
External Api type generation | api-update-registry-api-types.yaml |
i18n- |
Internationalization updates | i18n-update-core.yaml |
Documentation
Each workflow file contains comments explaining its purpose, triggers, and behavior. For specific details about what each workflow does, refer to the comments at the top of each .yaml file.
For GitHub Actions documentation, see Events that trigger workflows.