Bump Increments `PATCH` Version on `ci` Commit

[Clockwork-Muse]

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

1. Have a .cz.toml file:

   [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

2. Have a series of the following commit messages:
   • before_non_bump.md
   • bump.md
   • after_non_bump.md
3. 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

[Clockwork-Muse]

Side note: looking at my logs, I'm also getting patch commits for chore messages, but I'm not sure whether that's intended?

[bearomorphism]

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]

Previous messages as (the relevant portion of the) git.log.

The middle commit, ada7086fe63e0b17e4b5e2f617d52585176f33f4, was considered to have a patch bump

[bearomorphism]

Thanks!

[namwoam]

@bearomorphism I will take on this issue.

[bearomorphism]

@namwoam could you share the root cause of the unexpected behavior in this issue?

[woile]

Can you share the output of git log --decorate? Thanks

[namwoam]

Hello @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 24

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 fix keyword, 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.toml is not very practical. Allowing users to ignore all commits from a specific author seems to be a better solution.