fix(ci): anchor BREAKING CHANGE footer match to line start - #131
Conversation
The pending-bump safety check's major-bump regex matched "BREAKING CHANGE:" or "BREAKING-CHANGE:" anywhere in the commit log text, not just as an actual footer at the start of a line. PR #130's own squash-merge commit body included prose describing the fix ("...accept the hyphenated BREAKING-CHANGE: footer variant...") which matched the same way a real footer would, so the manual workflow_dispatch run wrongly reported a pending "major" release and blocked a "patch" request (https://github.com/GingerGraham/bash-logger/actions/runs/35742401239). Anchor the BREAKING CHANGE alternative to ^ like the type-prefix alternative already is, so only an actual footer line counts. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017KFf4oXoAAheW8AdAQ2q7G
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The one-character anchor fix is correct and complete, aligns with Conventional Commits footer semantics, and cannot introduce false negatives.
Review effort: Balanced
Findings: None
What changed in this PR
This PR fixes a bug in the manual workflow_dispatch pending-bump safety check added in #130. That check replicates .releaserc.json's release rules in bash to prevent a requested low bump from silently being escalated. The BREAKING[ -]CHANGE: alternative in its detection regex was not anchored to line start (unlike the sibling alternatives), so ordinary commit-body prose containing the words "BREAKING-CHANGE:" was mistaken for a real footer, wrongly escalating the pending bump to major and blocking a legitimate manual patch dispatch.
Changes:
- Anchor the
BREAKING[ -]CHANGE:regex alternative with^so only a real footer at line start counts as a breaking change.
| File | Description |
|---|---|
| .github/workflows/release.yml | Adds a ^ anchor to the BREAKING[ -]CHANGE: alternative in the manual-dispatch pending-bump detection regex, aligning it with the already-anchored type-prefix alternatives. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Summary
Fixes a real bug in #130's manual-dispatch pending-bump safety check, discovered when the
maintainer actually ran it: run 35742401239
failed claiming a
majorrelease was pending and blocked the requestedpatch, when theactual pending commit (
feat(ci): ...) should only have producedminor.Root cause
The pending-bump regex's
BREAKING[ -]CHANGE:alternative wasn't anchored to line-start —only the
<type>!:alternative had a leading^. PR #130's own squash-merge commit bodyincluded this line, describing the fix it made:
That's prose explaining the feature, not an actual Conventional Commits footer (which must
start its own line) — but the unanchored
grep -Ematched "BREAKING-CHANGE:" anywhere in thelog text, so it was treated the same as a real footer and wrongly escalated
PENDINGtomajor.Separately, the auto-push path (unaffected by this bug — it uses real
semantic-release, notthis bash heuristic) correctly cut
v2.6.0as a minor release, since the merge commit reallywas
feat(ci): .... That part worked as designed.Change
.github/workflows/release.yml: anchor theBREAKING CHANGE/BREAKING-CHANGEalternative to^like the type-prefix alternative already is, so only an actual footer line (not body prosementioning the words) counts.
Testing
(
git log -1 --format=%B 975307e) against the old regex — confirmed it wrongly returnsmajorminoragainst that same real commit body!:of any type, realBREAKING CHANGE:/BREAKING-CHANGE:footers on their own line, plainfeat:/fix:/chore:) — all passpython3 -c "import yaml; yaml.safe_load(...)")pre-commit run --files .github/workflows/release.yml— passedRelated issues
Follow-up to #130 — fixes the manual-dispatch failure reported after merge.
🤖 Generated with Claude Code
https://claude.ai/code/session_017KFf4oXoAAheW8AdAQ2q7G
Generated by Claude Code