ci: align breaking-change detector with release-it parser semantics#353
Merged
MarioCadenas merged 1 commit intomainfrom May 6, 2026
Merged
ci: align breaking-change detector with release-it parser semantics#353MarioCadenas merged 1 commit intomainfrom
MarioCadenas merged 1 commit intomainfrom
Conversation
Verified the regex case-by-case against `conventional-changelog-conventionalcommits` (the parser release-it actually uses) and tightened it so it matches release-it's notion of "this triggers a major bump" exactly: - Case-insensitive match on both subject `type!:` and the `BREAKING[ -]CHANGE` footer keyword (e.g. `Feat!:` and `breaking change: ...` both bump major in release-it). - Footer line allows leading whitespace (release-it accepts ` BREAKING CHANGE: ...`). - Footer keyword no longer requires a `:` (release-it accepts `BREAKING CHANGE foo`); we now end on a word boundary. - Plural `BREAKING CHANGES` is explicitly excluded with `\b(?!S)` because release-it does NOT treat it as breaking — flagging it would be a false positive that blocks harmless prose.
MarioCadenas
changed the title
MarioCadenas
changed the title
MarioCadenas
force-pushed
the
ci/breaking-change-detector-parity
branch
from
813d9ba to
40731b9
Compare
pkosiec
approved these changes
May 6, 2026
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
2 participants
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.
Summary
The detector added in #350 used a hand-rolled regex that didn't match what
release-it(viaconventional-changelog-conventionalcommits) actually treats as a major-bumping change. Surfaced while testing #352 — a PR withBREAKING CHANGES: ...(plural) in its description was passing the gate, but so were a few other inputs that release-it would silently bump major on.I instrumented the live parser and ran ~30 commit-message variants through
whatBump, then tightened the regex until it agreed with the parser on every case. The new regex differs in four ways:Feat!:,FEAT!:, andbreaking change: ...all bump major in release-it.BREAKING CHANGE: ...is a valid footer per the parser.BREAKING CHANGE foo(no colon) is a valid footer; the parser tokenizes on word boundary.BREAKING CHANGESis not breaking per the parser, so\b(?!S)keeps us from creating false positives on prose like "introduces some breaking changes:".Verified end-to-end against PR #352's actual inputs.
Test plan
BREAKING CHANGES: ...(plural) in the description does not trigger the gate.BREAKING CHANGE: ...(singular) in the description does trigger the gate.breaking change: ...(lowercase singular) does trigger the gate.Feat!: ...(mixed-case bang in title) does trigger the gate.