Skip to content

release: v3.2.3 - allow ' - <subject>' suffix on release commits - #17

Merged
Shinrai merged 3 commits into
masterfrom
fix/audit-allow-suffixed-release
May 21, 2026
Merged

Shinrai merged 3 commits into
masterfrom
fix/audit-allow-suffixed-release

Conversation

@cldmv-bot

@cldmv-bot cldmv-bot Bot commented May 21, 2026

Copy link
Copy Markdown
Contributor

🚀 What's Changed

💥 Breaking Changes

No breaking changes

✨ Features

No new features

🐛 Bug Fixes

🔧 Other Changes

No other changes

👥 Contributors

Shinrai and others added 3 commits May 21, 2026 06:31
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.
@cldmv-bot cldmv-bot Bot added release Marks a pull request as a pending release — merge to publish a new version semver: patch This release contains only backwards-compatible bug fixes type: bug Something is broken or not behaving as expected area: core labels May 21, 2026
@Shinrai
Shinrai merged commit d9b431c into master May 21, 2026
8 checks passed
@cldmv-bot
cldmv-bot Bot deleted the fix/audit-allow-suffixed-release branch May 21, 2026 14:20
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release Marks a pull request as a pending release — merge to publish a new version semver: patch This release contains only backwards-compatible bug fixes type: bug Something is broken or not behaving as expected

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant