You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Browse filesBrowse the repository at this point in the historyBrowse files
authored
ci(release): harden core-release workflow (fixes from 1.47.10) (#14039)
Hardens the core-release automation against concrete failures hit
shipping core **1.47.9 / 1.47.10 / 1.47.11**. All changes are additive —
they change no existing job's happy path.
Implements the SAFE, high-value items from #14033. The invasive
redesigns in that issue are intentionally left for owner input (see
*Left for owners* below).
> Rebased onto `main`. The workflow this PR hardens was renamed
`release-biweekly-comfyui.yaml` → `release-weekly-comfyui.yaml` while
this sat open; the changes moved with it.
## Changes
### 1. `release-draft-create.yaml` — a cosmetic comment can no longer
fail a good release
Added `continue-on-error: true` to the *"Post release summary comment"*
step.
**Evidence:** across six release runs (1.47.8/9/10, 1.48.3/4/5) `build`,
`draft_release` and `publish_types` all succeeded — tag cut, GH release
created, npm types published — but the comment step returned `403 Unable
to create comment because issue is locked` (the org-wide lock) and
marked the **whole run `failure`**. A false "release failed" signal on
six shipped releases. A comment is a nice-to-have; it must never gate
release success. The step still surfaces any crash in its own logs.
### 2. `release-draft-create.yaml` — Latest is reconciled in the same
run
`make_latest: false` only declines to *claim* Latest; GitHub still
surfaces the newest published release, so a patch on an older line takes
it anyway. v1.47.11 displaced v1.49.1 this way and had to be restored by
hand — three times in one release session.
#14618 landed `release-enforce-latest.yaml`, which owns the
greatest-semver-wins policy. Its own `release` trigger **cannot** cover
the automated path: the release is created with the repository's
`GITHUB_TOKEN`, and `GITHUB_TOKEN`-driven actions never emit events that
start a new workflow run — so on this path it would only self-heal at
the next daily cron, leaving `--front-end-version latest` pointing at an
older release for up to a day.
Rather than ship a second implementation of the same policy, this PR
exposes that workflow via `workflow_call`, declares only the required
`PR_GH_TOKEN`, and invokes it as a new `enforce_latest` job after
`draft_release`. The job recomputes the true-latest release from scratch
and has no dependency on `github.event.release.*` context. One
implementation, corrected immediately, in the same run — zero delay
instead of up to 24h.
### 3. `release-weekly-comfyui.yaml` — tag-wait timeout no longer
silently drops the pin PR
The `publish-pypi` *"Wait for release PR to be created and merged"* step
polled for the tag for **30 min** then hard-failed. Because
`create-comfyui-pr` has `needs: publish-pypi` + `if: …
publish-pypi.result == 'success'`, that timeout also **skipped
`create-comfyui-pr`**, silently losing the ComfyUI pin PR.
**Evidence:** run
[`29979988134`](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/29979988134)
— the bump PR wasn't merged within 30 min; recovery was a manual `gh run
rerun 29979988134 --failed` after the tag existed.
- **Raise the poll window to 4h** — a human merging a `Release`-labeled
bump PR realistically isn't a 30-min operation.
- **Make the timeout self-documenting** — on timeout the step emits a
`::error::` annotation *and* a job-summary block naming both possible
causes in order, plus the exact recovery command.
### 4. `release-weekly-comfyui.yaml` — wait for PyPI before opening the
pin PR
PyPI's index lags the upload by a minute or two, so a pin PR opened
immediately fails its own CI on `No matching distribution found` and
reads as a bad bump. Adds a wall-clock-bounded (15m) probe; on timeout
the pin PR still opens, with the body flagging the availability as
unconfirmed.
### 5. `release-weekly-comfyui.yaml` — new `release-done` assertion job
Fails loudly (annotations + job summary) if a just-published release
didn't actually reach users:
- **Stranded commits** (hard fail): `git rev-list vTAG.. --count != 0` —
the **1.47.9** case, where `v1.47.9` published while 19 QA-fix commits
sat unreleased past the tag and only a manual `git rev-list` caught it.
- **PyPI** (hard fail): the target version must be present on PyPI. For
`main`-line releases it must also be PyPI's `latest`; `core/*` patches
are intentionally non-`latest`, so that sub-check is informational
there.
## Left for owners (issue discussion, not this PR)
- **Full decoupling** of the PyPI publish into a `release:`-triggered
workflow. Bigger design change; would eliminate the poll entirely. Note
the `GITHUB_TOKEN` constraint above — a `release:` trigger needs a
PAT/App token to fire at all.
- **Getting real CI onto the release branches** — policy/infra decision.
Addresses the safe parts of #14033.
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Connor Byrne <c.byrne@comfy.org>
Co-authored-by: Alexander Brown <drjkl@comfy.org>
Co-authored-by: DrJKL <DrJKL0424@gmail.com>
Co-authored-by: Amp <amp@ampcode.com>
Co-authored-by: GitHub Action <action@github.com>
if [ "$CURRENT_LATEST_TAG" == "$TRUE_LATEST_TAG" ]; then
94
-
echo "OK: 'latest' already matches the highest stable semver release. No action needed."
95
-
exit 0
96
-
fi
97
-
98
-
echo "::warning::'latest' is currently '${CURRENT_LATEST_TAG:-<none>}' but the highest stable semver release is '$TRUE_LATEST_TAG'. Reassigning 'latest' to '$TRUE_LATEST_TAG'."
echo "- Status: ✅ Published and confirmed available" >> $GITHUB_STEP_SUMMARY
275
+
echo "- Installable from PyPI: ${{ steps.pypi-wait.outputs.confirmed }}" >> $GITHUB_STEP_SUMMARY
294
276
295
277
create-comfyui-pr:
296
278
needs:
@@ -372,7 +354,11 @@ jobs:
372
354
EOF
373
355
)
374
356
375
-
PYPI_NOTE="✅ **PyPI package confirmed available** — \`comfyui-frontend-package==${{ needs.resolve-version.outputs.target_version }}\` has been published and verified."
357
+
if [ "${{ needs.publish-pypi.outputs.pypi_confirmed }}" = "true" ]; then
358
+
PYPI_NOTE="✅ **PyPI package confirmed available** — \`comfyui-frontend-package==${{ needs.resolve-version.outputs.target_version }}\` has been published and verified."
359
+
else
360
+
PYPI_NOTE="⚠️ **PyPI availability unconfirmed** — \`comfyui-frontend-package==${{ needs.resolve-version.outputs.target_version }}\` was not installable from PyPI before the wait expired. CI here may fail until the index catches up."
0 commit comments