Repository navigation
Bump Increments PATCH Version on ci Commit #1772
Description
Description
I've just received a patch bump on a CI commit, when neither the preceding nor succeeding CI commit resulted in a bump at all.
This is possibly the same cause as #695, as the auto-generated messages from dependabot includes "matching" messages in some cases in the body.
Steps to reproduce
- Have a
.cz.tomlfile:[tool.commitizen] name = "cz_conventional_commits" tag_format = "v$version" version_scheme = "semver2" version_provider = "scm" annotated_tag = true breaking_change_exclamation_in_title = true
- Have a series of the following commit messages:
- Run
cz --no-raise 21 bump --get-next, and observe that it outputs a version bump
(I'm sorry, this is a private repo, so I can't point you at a repo itself)
Current behavior
It unexpectedly issued a new bump version.
If a changelog is generated, eg with cz changelog v<new version> --file-name <some file name>, it outputs a changelog without a list of changes:
## v0.2.1 (2026-01-05)Desired behavior
No version bump
Screenshots
No response
Environment
Commitizen Version: 4.11.0
Python Version: 3.11.2 (main, Apr 28 2025, 14:11:48) [GCC 12.2.0]
Operating System: Linux
Activity
Clockwork-Muse commentedon Jan 5, 2026
Side note: looking at my logs, I'm also getting patch commits for
choremessages, but I'm not sure whether that's intended?bearomorphism commentedon Jan 7, 2026
Sounds strange, at least it does not happen on our project github action. We have merged a few ci / build commits recently but we didn't observed this.
Can you share the commit log? I am not entirely sure what your attached markdown files mean. Which commit(s) triggered the undesired behavior?
It would be easier for us to debug if we have the commits.
Clockwork-Muse commentedon Jan 7, 2026
Previous messages as (the relevant portion of the) git.log.
The middle commit, ada7086fe63e0b17e4b5e2f617d52585176f33f4, was considered to have a patch bump
bearomorphism commentedon Jan 8, 2026
Thanks!
namwoam commentedon Jan 31, 2026
@bearomorphism I will take on this issue.
bearomorphism commentedon Feb 8, 2026
@namwoam could you share the root cause of the unexpected behavior in this issue?
woile commentedon Feb 8, 2026
Can you share the output of
git log --decorate? Thanksnamwoam commentedon Feb 8, 2026
Hello @bearomorphism @woile
In the git log, line 91 contains the following commit message:
Based on the logic in bump.py, this message matches the pattern
^((BREAKING[\-\ ]CHANGE|\w+)(\(.+\))?!?):defined in defaults.py
As a result, because the message contains the
fixkeyword, it is interpreted as a patch bump.That said, it’s difficult to anticipate every edge case where the regex might produce unintended matches. For this reason, it seems more robust to allow users to explicitly control which commits should NOT trigger a version bump.
Additionally, requiring users to list every commit (potentially hundreds) generated by tools like Dependabot in
pyproject.tomlis not very practical. Allowing users to ignore all commits from a specific author seems to be a better solution.woile commentedon Feb 8, 2026
Nothing wrong here, it works as expected
If you don't want commits from dependabot to be part of the bump, just change dependabot.
I disagree, it just creates confusion.
Without a full log, we cannot tell if there's a bug or not, but, looking at the title, if there was a
fixcommit, then a PATCH is expected, and it worked well.bearomorphism commentedon Feb 9, 2026
So it's by design. The new feature in #1853 is not necessary.
bearomorphism commentedon Feb 9, 2026
@Clockwork-Muse I am closing this issue since everything is working as expected here. Feel free to reopen this issue if you think further discussion is needed. Thanks!
Clockwork-Muse commentedon Feb 9, 2026
@bearomorphism - I don't have permission to re-open the issue.
The problem here is that that isn't the (start of the) commit message, it's about halfway down the body of the message. The actual start of the commit message is indeed
"ci:", on line 11, which is why I was expecting to be the determining factor.The message causing the bump to be chosen is from the changelog of the dependency dependabot is bumping not from commits in my repo. It's dependabot showing its work, and it looks like this in the UI:
The decorated log reveals only whitespace differences, plus the tag that got attached from a release, but nothing otherwise substantive.
Lee-W commentedon Feb 10, 2026
I just re-open the issue for further discussion
bearomorphism commentedon May 9, 2026
Triage from #1964: Already assigned and reopened — leaving in place. Logging here for tracking.
bearomorphism commentedon May 9, 2026
Verification update (re #1964)
Reproduced against current master (4.15.1):
Bulleted body (e.g.,
- fix: addresses CVE-...inside aci:commit body) does NOT trigger a false-positive bump — the leading-prevents the regex match.Unbulleted body line that starts at column 0 with a conventional-commit form (e.g.,
fix: update @actions/artifact to ^5.0.0 for Node.js 24inside another commit's body) DOES still trigger a false-positive PATCH bump:The body line is also picked up by the changelog and rendered as a
### Fixentry.Verdict: STILL VALID. Root cause: in
commitizen/bump.py::find_increment, thebump_patternis matched against every line ofcommit.message.split("\n"), including the body. Any line that happens to start withfeat/fix/etc. counts as a bumpable commit type — even if it's just text in the body of aci:or merge-commit.Possible fixes:
commit.title, not the body).revert/mergewhere body parsing makes sense.re.fullmatchon each line so a line like "fix: update X" doesn't match if there's any prefix/whitespace — but this is fragile.(1) feels safest. Worth coordinating with whoever's already assigned (@namwoam) so we don't double up.
bearomorphism commentedon May 9, 2026
Update (re #1964 triage)
@namwoam — pinging in case you're still active on this. Given the thread has been quiet since February, I went ahead and put up #1983 so the fix doesn't sit. If you'd rather take it over, please say the word and I'll close mine.
Re-reading the screenshot @Clockwork-Muse attached (the dependabot PR description, which becomes the commit body):
The
b5b1a91 fix: update @actions/artifact to ^5.0.0 for Node.js 24 punycode fixline is dependabot quoting an upstream commit fromactions/upload-artifact's changelog — it's NOT afix:commit in @Clockwork-Muse's repo. The actual repo commit isci: bump actions/upload-artifact from 5 to 6 (#23).My earlier triage closed this as "by design", which was wrong. The Conventional Commits spec puts the type only in the title. Scanning every body line for type-prefixed text is what conflicts with the spec, and what produces this kind of false positive on auto-generated commits.
The fix in #1983:
find_incrementmatches the type only againstcommit.title. The body is still scanned, but only forBREAKING CHANGE:/BREAKING-CHANGE:footers (which the spec puts in the body / footer). Existing tests for both forms (title + body BREAKING CHANGE) still pass; the new regression test reproduces the dependabot scenario.Sorry for the previous closure, @Clockwork-Muse. Verified end-to-end with your exact reproducer.