Open pdarulewski opened 1 year ago
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
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
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 https://github.com/commitizen-tools/commitizen/blob/d19007e0e4caa8da96326ce28ddcb70c5b3e1dff/commitizen/defaults.py#L108-L117
@woile Please correct me if I'm wrong.
In the meantime, I'll turn this into a documentation fix
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.
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
@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.
@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
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).
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
Although, if I select the
BREAKING CHANGE
, it's bumped.Current behavior
As you can see, I can't bump the version after committing a
build
change. I also noticed thatci
is not eligible either, so probably more of the commits type are influenced by this. Documentation says that everything other than aBREAKING CHANGE
andfeat
should be bumped asPATCH
, 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 asPATCH
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
EDIT:
ci
being influenced too