Repository navigation
release: v3.2.3 - allow ' - <subject>' suffix on release commits - #17
Merged
Merged
Conversation
local-master-commit-audit.yml's allowed_patterns for release commits was strict: '^release: v\d+\.\d+\.\d+( \(#\d+\))?$'. Accepts the bare form and the squash-appended ' (#N)' PR ref, nothing else. After title-suffix landed (v3.2.0, PR #11), every release PR — and therefore every squash-merge commit on master — carries a ' - <descriptive subject>' tail. The audit then files an 'audit: non-conforming commit subject' issue on every release. PR #15's merge just produced issue #14 against: release: v3.2.2 - match suffixed release-PR titles in sync-fan-out filter (#15) Pattern update to mirror the format check-release-commit emits: ^release: v\d+\.\d+\.\d+( - .+?)?( \(#\d+\))?$ Accepts: - 'release: v3.2.2' - 'release: v3.2.2 (#15)' - 'release: v3.2.2 - description' - 'release: v3.2.2 - description (#15)' Rejects (still treated as non-conforming): - 'release: v3.2.2-bad' (no space before dash) - 'release: v3.2.2 bad-no-dash' (no ' - ' separator) The ' - ' is required as a separator when a subject is present, matching the format the release flow emits.
update-release-pr/action.yml passes 'ref: ${{ inputs.head-ref }}' to
checkout-code, but the checkout-code wrapper on master only declares
'fetch-depth' as an input. actionlint flags this as 'Invalid action
input 'ref'' and local CI fails on any branch off master that doesn't
already include the fix.
PR #10 (fix/checkout-code-ref-and-trivy) has the same one-line fix —
it's the original reason the PR was opened. Adding the same change
here so this branch's local CI passes; whichever PR merges first lands
the fix on master, the other becomes a no-op delta on its file.
Shinrai
added a commit
that referenced
this pull request
May 21, 2026
…race Real-world failure traced from PR #10's logs: when a release PR merges to master, two workflows fire in parallel — 🏷️ Update Major Version Tags (rolls @V3 to the new commit) and 🔄 Local Sync Open Release PRs (refreshes every open release PR). If sync-fan-out resolves its `uses: ...@v3` refs BEFORE tag-update lands the new @V3, it pulls the PREVIOUS release's code. Concrete symptom: checkout-code without the `ref:` input declared (fixed in PR #17). update-release-pr's checkout step then ignores the `ref: ${{ inputs.head-ref }}` input, falls through to actions/checkout's default = github.ref = refs/heads/master, checks out master instead of the release branch, runs find-divergence on master vs master, gets 0 commits in range, and silently exits without refreshing the PR. Every release merge from PR #11 onward hit this race; PR #10 was visibly stuck behind master as a result. Fix: add a wait-for-tags job at the head of the dependency chain. Polls refs/tags/v3 against github.sha (the merge commit) every 5 seconds for up to 2 minutes. enumerate now `needs: wait-for-tags`; refresh transitively waits via enumerate. If @V3 never advances (non-release merges where Update Major Version Tags doesn't fire), the poll times out and downstream jobs proceed — that's the right behaviour, since @V3 wouldn't have moved anyway. User-visible: future release-PR merges will see sync-fan-out fire ~30–60s later than before, but with action code that actually matches the just-merged master state. The release PRs in flight finally get their bumps recalculated against the new base. This also pushes a commit to PR #10, re-triggering its release flow. Since @V3 has now rolled forward to v3.2.3 (with the ref input declared), this run will check out PR #10's branch correctly and recalculate target = patch(3.2.3) = 3.2.4.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🚀 What's Changed
💥 Breaking Changes
No breaking changes
✨ Features
No new features
🐛 Bug Fixes
🔧 Other Changes
No other changes
👥 Contributors