Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.31%. Comparing base (d914b4d) to head (1e56d63).
⚠️ Report is 1 commits behind head on master.

@@            Coverage Diff             @@
##           master    #2078      +/-   ##
==========================================
+ Coverage   98.19%   98.31%   +0.11%     
==========================================
  Files          61       61              
  Lines        2829     2851      +22     
==========================================
+ Hits         2778     2803      +25     
+ Misses         51       48       -3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

How is this any different from bump_pattern?

To illustrate the use case, consider the example commit sequence from #2075. In this monorepo, commits related to applications AppA and/or AppB are identified through a custom Applications: line in the commit message:

-- Commit 1 -----
feat: implement library

Applications: ['AppA', 'AppB']

-- Commit 2 -----
fix: fix nasty bug

Applications: ['AppB']

-- Commit 3 -----
ci: change release pipeline

Applications: ['AppA', 'AppB']

-- Commit 4 -----
...

When calculating the version bump for AppA, only commits that affect AppA should be considered. In this example, bump_commit_filter_pattern could be configured as:

(?s)^.*Applications:.*'AppA'.*\].*

This pattern selects only commits that relate to AppA.

bump_pattern cannot be used for this purpose because it is evaluated line by line, rather than against the full commit message.

As implemented today in find_increment() in commitizen/bump.py:

for commit in commits:
    for message in commit.message.split("\n"):
        result = select_pattern.search(message)

(where select_pattern is bump_pattern)

By contrast, bump_commit_filter_pattern would act as a pre-filter on the list of commits considered for version bump calculation and would evaluate the entire commit message. In my PR, this is implemented in filter_commits() in commitizen/bump.py:

return [commit for commit in commits if select_pattern.match(commit.message)]

(where select_pattern is bump_commit_filter_pattern)

I do not think bump_pattern itself can be changed to evaluate the full commit message without introducing a backward compatibility break.

Today, Commitizen evaluates each line of a commit message against bump_pattern, determines whether that line implies a PATCH, MINOR, MAJOR, or no bump, and then uses the highest bump level found within the commit. Existing configurations may rely on this behavior, including the ability to map different lines of the same commit message to different bump levels via bump_map.

For that reason, I see bump_commit_filter_pattern as complementary to bump_pattern rather than a replacement: it decides whether a commit should participate in bump calculation at all, while bump_pattern continues to decide which bump level a selected commit contributes.

Yes, but it's the same, now we evaluate twice the commit message.

Why not a setting like split_commit_message?

for commit in commits:
    messages = commit.message.split("\n") if split_commit_message else [commit.message]
    for message in messages:
        result = select_pattern.search(message)

Mmh, I would still like to support commit messages such as the following:

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

Applications: ['AppA', 'AppB']

When calculating the version bump for AppA, I would first want to identify this commit as relevant using a bump_commit_filter_pattern such as:

(?s)^.*Applications:.*'AppA'.*\].*

The commit would then participate in the bump calculation. After that, I would still want the existing bump_pattern / bump_map logic to analyze the commit line by line in order to determine the bump level. In this example, both feat and BREAKING CHANGE would be evaluated, and the resulting bump level would be the highest one found.

This is why I currently do not see how a setting such as split_commit_message would solve the problem. These are actually two separate concerns:

1. Commit filtering: Decide whether a commit is relevant for a particular application. This requires evaluating the entire commit message.
2. Bump calculation: Determine the bump level (PATCH, MINOR, MAJOR) for a relevant commit. This currently relies on evaluating the commit line by line.

In my use case, both behaviors are needed at the same time.

The proposed bump_commit_filter_pattern is intended to address only the first concern. It acts as a pre-filter that decides whether a commit should be considered at all during bump calculation. Once a commit has been selected, the existing bump_pattern behavior can remain unchanged.

This would also be analogous to changelog_pattern, which is used to select commits for changelog generation based on the full commit message. In #2075 I considered reusing changelog_pattern for this purpose, but currently I prefer a dedicated configuration option because changelog generation and bump calculation are conceptually separate features.