fix(commits): accept ! breaking-change marker in subject#32
Conversation
Conventional Commits 1.0 defines ! after the type/scope as equivalent to a BREAKING CHANGE footer. The validator regex only accepted the footer form, rejecting spec-valid subjects like feat(api)!: drop x. Add an optional !? before the colon.
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request updates the commit message validation logic to align with the Conventional Commits 1.0 specification. By allowing the '!' character before the colon in commit subjects, the validator now correctly handles breaking changes as defined by the spec, preventing valid commits from being rejected by CI. Highlights
Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. A bang in the subject line found, / Where breaking changes now abound. / The regex was tight, / But now it is right, / And spec-compliant commits are unbound. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the CHANGELOG.md to document a fix for the reusable-conventional-commits.yml workflow, allowing the ! breaking-change marker in commit subjects. The reviewer noted that the actual code changes to the workflow file are missing from the PR and suggested a wording improvement in the changelog to accurately reflect the project's release history.
There was a problem hiding this comment.
Pull request overview
This PR updates the reusable Conventional Commits validator to accept the spec-compliant ! breaking-change marker in the commit subject (e.g. feat(api)!: …), and records the fix in the changelog.
Changes:
- Loosen the commit-subject validation regex to allow an optional
!before the colon. - Add a
0.6.1changelog entry documenting the validator fix.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
CHANGELOG.md |
Adds a 0.6.1 entry describing acceptance of ! in Conventional Commit subjects. |
.github/workflows/reusable-conventional-commits.yml |
Updates the grep -P regex to allow ! after type/scope, before :. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The 0.6.0 release commit had to be rewritten to drop the ! marker to pass CI under the old regex. Say "intended" rather than "used" so the entry matches the actual git history.
|
Released as v0.6.1 |
Summary
reusable-conventional-commits.ymlto allow an optional!between the type/scope and the colon, so spec-compliant breaking-change subjects likefeat(api)!: drop xpass validation.## [0.6.1].Why
Conventional Commits 1.0 defines two equivalent ways to mark a breaking change:
!after the type/scope, before the colon — e.g.feat(stale)!: drop legacy inputsBREAKING CHANGE:footer in the bodyThe validator regex only accepted the footer form. The 0.6.0 release commit (
feat(stale)!: per-type timeouts for issues and PRs) was rejected by CI, forcing a rewrite of the subject to drop the!and rely solely on the body footer. Both forms are spec-valid; the validator should accept either.Change
The
!?is zero-or-one literal!, composing correctly with the optional scope group.Test plan
Smoke-tested locally — all four spec-valid forms pass, and previously-rejected non-conventional input still rejects:
feat: foofeat!: foofeat(api): foofeat(api)!: foofeat(api):(empty subject)random textactionlintcleanfix(commits): accept ! breaking-change marker in subject(which itself does not use!, so this PR can land cleanly under the old regex)Compatibility
Pure loosening — every previously-accepted subject is still accepted. No caller changes required.