build commit is not eligible to be bumped

[pdarulewski]

Description

Hello,

Thanks for creating and maintaining this great library 🙏

I found out that build: commits don't qualify as eligible for bumping anymore. I couldn't find any information if this is an expected behaviour, so I guess it might be a potential bug. It seems that it was working in 3.2.1 since it was the version that I was using before updating to the latest one.

Steps to reproduce

𝝺 cz c
? Select the type of change you are committing build: Changes that affect the build system or external dependencies (example scopes: pip, docker, npm)
? What is the scope of this change? (class or file name): (press [enter] to skip)
 
? Write a short and imperative summary of the code changes: (lower case and no period)
 dockerfile parent image update
? Provide additional contextual information about the code changes: (press [enter] to skip)
 
? Is this a BREAKING CHANGE? Correlates with MAJOR in SemVer No
? Footer. Information about Breaking Changes and reference issues that this commit closes: (press [enter] to skip)
 

build: dockerfile parent image update


[feat/dockerfile 71292a7] build: dockerfile parent image update
 1 file changed, 1 insertion(+), 1 deletion(-)

Commit successful!
𝝺 cz bump
[ci skip] bump: 0.2.0 → 0.2.0
tag to create: v0.2.0

[NO_COMMITS_TO_BUMP]
The commits found are not eligible to be bumped

Although, if I select the BREAKING CHANGE, it's bumped.

𝝺 cz c
? Select the type of change you are committing build: Changes that affect the build system or external dependencies (example scopes: pip, docker, npm)
? What is the scope of this change? (class or file name): (press [enter] to skip)
 
? Write a short and imperative summary of the code changes: (lower case and no period)
 dockerfile
? Provide additional contextual information about the code changes: (press [enter] to skip)
 
? Is this a BREAKING CHANGE? Correlates with MAJOR in SemVer Yes
? Footer. Information about Breaking Changes and reference issues that this commit closes: (press [enter] to skip)
 

build: dockerfile

BREAKING CHANGE: 


[feat/dockerfile 3439504] build: dockerfile
 1 file changed, 1 insertion(+), 1 deletion(-)

Commit successful!
𝝺 cz bump
[ci skip] bump: 0.2.0 → 1.0.0
tag to create: v1.0.0
increment detected: MAJOR

[feat/search-gate 2404a26] [ci skip] bump: 0.7.0 → 1.0.0
 3 files changed, 4 insertions(+), 4 deletions(-)

Done!

Current behavior

As you can see, I can't bump the version after committing a build change. I also noticed that ci is not eligible either, so probably more of the commits type are influenced by this.
Documentation says that everything other than a BREAKING CHANGE and feat should be bumped as PATCH, here's the link.

It works for breaking changes, so it seems it takes precedence over the commit types.

Desired behavior

I would argue that commits related to the build process, e.g. docker image version, O flags for the compiler, pip dependency updates, poetry.lock update, etc. should be bumped as PATCH at least. These changes may not necessarily change the code behaviour but they certainly change the environment and the state of the codebase which may lead to unexpected results.

I don't want to replace such commits with feats or fixes since the code itself is not changed.

If this is an expected behaviour, it would be good to reflect that in the documentation.

Screenshots

No response

Environment

𝝺 cz version --report
Commitizen Version: 3.5.2
Python Version: 3.11.4 (main, Jun 20 2023, 17:23:00) [Clang 14.0.3 (clang-1403.0.22.14.1)]
Operating System: Darwin

EDIT:

• added a note about ci being influenced too

[Lee-W]

I just traced the code a bit, and it seems to be the case from long ago 🤔 Not sure why it works that way on 3.5.2, but I'll take a look

[alexnazarv]

Hi!
I have the same behavior

Commitizen Version: 3.8.0
Python Version: 3.10.10 (main, Aug 12 2023, 11:42:25) [GCC 11.3.0]
Operating System: Linux

[Lee-W]

I think this is misleading content in https://commitizen-tools.github.io/commitizen/bump/#:~:text=fix%20%2B%20everything%20else.

Not everything should be bumped as a PATCH. e.g., doc is most likely not related to version.

The source code is

commitizen/commitizen/defaults.py

Lines 108 to 117 in d19007e

	bump_map = OrderedDict(
	(
	(r"^.+!$", MAJOR),
	(r"^BREAKING[\-\ ]CHANGE", MAJOR),
	(r"^feat", MINOR),
	(r"^fix", PATCH),
	(r"^refactor", PATCH),
	(r"^perf", PATCH),
	)
	)

@woile Please correct me if I'm wrong.

In the meantime, I'll turn this into a documentation fix

[woile]

I think conventional commits only defines feat and fix and you can always add the BREAKING CHANGE block.
All others should be user defined.

I think our conventional_commits_cz is outdated, we should come up with a conventional_commits_cz_v1, potentially adding the ability for users to add their own mappings.

I couldn't find anywhere what should happen with build, ci, etc. Some argue it should bump, some that it should be ignored. commitizen at the moment is ignoring them, unless a BREAKING CHANGE block is present in the commit message.

[pdarulewski]

I am fine with build and ci not being bumped, I defined my custom rules in pyproject.toml file so it works as I wanted to 👍 then I guess it's just the matter of updating the docs

[DaDlugosch]

@pdarulewski Could you please send here a snippet of your pyproject.toml configuration file where you define custom rules? I would like to bump a new patch version with build and ci commit type, but I don't know how to achieve it by local configuration. However, I'm running commitizen on NPM project, so I hope it would be no problem to implement it. I'm using .cz.yaml configuration file in the root of the project.

[pdarulewski]

@DaDlugosch sure, here you go:

[tool.commitizen]
version = "1.2.3"
version_files = [
  "app/__init__.py:__version__",
  "pyproject.toml:version",
]
name = "cz_customize"

[tool.commitizen.customize]
bump_pattern = '^(feat|fix|ci|build|perf|refactor|my_custom_one)'
bump_map = { feat = "MINOR", fix = "PATCH", ci = "PATCH", build = "PATCH", perf = "PATCH", refactor = "PATCH", 'my_custom_one' = "PATCH" }
schema_pattern = '^(build|ci|docs|feat|fix|perf|refactor|style|test|chore|revert|bump|my_custom_one)(\(\S+\))?\:?\s.*'

To enable customised rules in the [tool.commitizen.customize], you have to provide name = "cz_customize" in the [tool.commitizen] config section.

Docs are saying that it's only possible through toml: https://commitizen-tools.github.io/commitizen/config/#customize

[johanvergeer]

I just upgraded to the latest version and it doesn't seem to work yet:

This is my git log. I tried to run cz bump --yes after every commit:

bump: version 1.7.0 → 1.7.1
refactor: test
bump: version 1.6.1 → 1.7.0
feat: test
build: test
ci: test
ci: test
chore: test
bump: version 1.6.0 → 1.6.1
refactor: test

I tried this config in pyproject.toml, cz.toml and .cz.toml, but none of them seem to work:

[commitizen.customize]
bump_pattern = '^(feat|fix|ci|build|perf|refactor|chore)'
bump_map = { feat = "MINOR", fix = "PATCH", ci = "PATCH", build = "PATCH", perf = "PATCH", refactor = "PATCH", chore = "PATCH" }
schema_pattern = '^(build|ci|docs|feat|fix|perf|refactor|style|test|chore|revert|bump)(\(\S+\))?\:?\s.*'

In short: feat, fix, and refactor allow a bump, all the others do not.

I'm on the latest version (3.27.0).