Repository navigation
Bump Increments PATCH Version on ci Commit #1772
Description
Activity
Side note: looking at my logs, I'm also getting patch commits for
choremessages, but I'm not sure whether that's intended?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.
Previous messages as (the relevant portion of the) git.log.
The middle commit, ada7086fe63e0b17e4b5e2f617d52585176f33f4, was considered to have a patch bump
Reacted by Tim HsiungThanks!
@bearomorphism I will take on this issue.
Reacted by Tim Hsiung and Wei Lee@namwoam could you share the root cause of the unexpected behavior in this issue?
Reacted by andre.liangCan you share the output of
git log --decorate? ThanksHello @bearomorphism @woile
In the git log, line 91 contains the following commit message:
fix: update <code>@actions/artifact</code> to ^5.0.0 for Node.js 24Based on the logic in bump.py, this message matches the pattern
^((BREAKING[\-\ ]CHANGE|\w+)(\(.+\))?!?):
defined in defaults.pyAs 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.As a result, because the message contains the fix keyword, it is interpreted as a patch bump.
Nothing wrong here, it works as expected
Additionally, requiring users to list every commit (potentially hundreds) generated by tools like Dependabot in pyproject.toml is not very practical
If you don't want commits from dependabot to be part of the bump, just change dependabot.
Allowing users to ignore all commits from a specific author seems to be a better solution.
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.As a result, because the message contains the
fixkeyword, it is interpreted as a patch bump.So it's by design. The new feature in #1853 is not necessary.
@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!
@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.
I just re-open the issue for further discussion
Triage from #1964: Already assigned and reopened — leaving in place. Logging here for tracking.
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:bump: version 0.1.0 → 0.1.1 tag to create: v0.1.1 increment detected: PATCHThe 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:
- Anchor the search to commit titles only (only check
commit.title, not the body). - Or, only check body lines when the title's type is something like
revert/mergewhere body parsing makes sense. - Or, use
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.
- Anchor the search to commit titles only (only check
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.
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
.cz.tomlfile: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