Repository navigation
release.yml self-triggers on its own changelog commit → spurious release (latent infinite loop once #11853 lands) #11855
Description
Umbrella: #11825 — CRITICAL, couples with #11853
Bug (latent infinite release loop)
release.yml runs on: push: branches: [main]. Its own final steps commit a chore(release): changelog… commit and open a PR that merges that commit to main. That merge is a push to main → re-triggers release.yml. git-cliff then patch-bumps off the release range (the promotion merge's fix history is attributed to "unreleased") and mints ANOTHER release.
Observed live: after the v0.5.1 changelog PR (#11851) was merged to main, run 29612048948 fired and git-cliff --bumped-version returned v0.5.2 (CLIFF_CONTENT: v0.5.2), publishing a spurious v0.5.2 tag+release from nothing but the changelog chore commit.
It stopped at one extra release ONLY because the changelog-PR step is currently failing on the missing pull-requests: write permission (#11853). Once #11853 is fixed, this becomes an unbounded loop: v0.5.2 → changelog PR merges → v0.5.3 → … So #11853 must NOT merge without this guard.
Fix
The changelog commit touches ONLY CHANGELOG.md and changelog/** (verified: commit 0afb93b = CHANGELOG.md + changelog/v0.5.1.md only). Add paths-ignore so a push limited to those paths never triggers the workflow:
on:
push:
branches: [main]
paths-ignore:
- CHANGELOG.md
- changelog/**A real promotion merge always touches other files too, so it still triggers; only the workflow's own changelog commit is filtered out.
Acceptance Criteria
- release.yml has
paths-ignore: [CHANGELOG.md, changelog/**] - Merging a changelog PR to main does NOT trigger a new release run
- A normal promotion (non-changelog files) still triggers exactly one release
Activity
fix(release): paths-ignore changelog files to break self-trigger loop (…
fix(release): grant pull-requests:write so changelog PR step succeeds (…
mrveiss commentedon Jul 18, 2026
Fixed via #11854 (merged to Dev_new_gui).
on.push.paths-ignore: [CHANGELOG.md, changelog/**]added (release.yml:23-25). Changelog commit touches only those paths (verified: 0afb93b), so it no longer self-triggers. The spurious v0.5.2 it produced was deleted. Activates at next promotion.mrveiss commentedon Sep 28, 2026
First live exercise of the loop guard, 2026-09-28 — it held
Until today the changelog PR could not be created (#15167), so the
paths-ignore: [CHANGELOG.md, changelog/**]guard onrelease.ymlhad never been reached. Today:The merge commit touched only the ignored paths, and no second
release.ymlrun appeared. The infinite-loop case this issue describes did not occur on the first occasion it could have.One observation, not a criterion: the guard is a path predicate. It holds as long as the changelog commit touches nothing outside those two paths — which the workflow controls — and it would not hold if a future change to the changelog step wrote anywhere else.