Repository navigation
Bump Increments PATCH Version on ci Commit #695
Description
Description
commitizen-action cut a spurious patch release when we merged a ci commit, ScribeMD/slack-templates@e2d9df0, to main, because cz bump incorrectly committed a bump. We made many ci commits previously without encountering this issue, and I am not sure what was special about this case.
Steps to reproduce
-
Run
git clone git@github.com:ScribeMD/slack-templates. -
Run
git checkout 0.6.17^to checkout the commit that triggered the spurious release. -
Refer to our contributing guide if desired to maximize fidelity between our dev environments, but you can most likely get away with simply running commitizen 2.42.1.
-
Run
poetry run cz --no-raise 21 bump --yes --changelog --check-consistency --dry-run. (Omit thepoetry runportion if you didn't follow our contributing guide and installed commitizen some other way.) -
Observe the following output:
bump: version 0.6.16 → 0.6.17 tag to create: 0.6.17 increment detected: PATCH ## 0.6.17 (2023-04-05)
Current behavior
Here is the pertinent output from commitizen-action:
Commitizen version: 2.42.1
cz --no-raise 21 bump --yes --changelog --check-consistency
bump: version 0.6.16 → 0.6.17
tag to create: 0.6.17
increment detected: PATCH
Desired behavior
Commitizen shouldn't increment the version number when there are no feat, fix, or refactor commits since the previous tag, 0.6.16 in this case.
Screenshots
No response
Environment
- Commitizen version: 2.42.1
- Python version: 3.11.2
- Operating system: Linux
Activity
woile commentedon Apr 5, 2023
Could you share the commit log? Summary and body of each commit message?
My first guess would be that there was another commit in the branch that triggered the patch
Kurt-von-Laven commentedon Apr 5, 2023
Here is the log, but as you can see there are only
chore,docs, andstylecommits in addition to the lonecicommit at the end. We run the commitizen-action after every merge to main and only merge one commit at a time, so it would be even more mysterious if the preceding commits factored into this bug.Kurt-von-Laven commentedon Apr 7, 2023
A subsequent
cicommit didn't trigger a release. Still not sure what was different about ScribeMD/slack-templates@e2d9df0.Kurt-von-Laven commentedon Apr 7, 2023
I believe the issue is that one of the lines of the body of the commit message started with the characters "perf," and Commitizen searches the full commit message. It seems like it should only search the subject with the exception of
BREAKING CHANGES?woile commentedon Apr 7, 2023
I think it supports parsing the body for simplicity, this way the regex can include
BREAKING CHANGE.Which commit has the
perf? I think it should only parse if it'sperf:, rather than just perfKurt-von-Laven commentedon Apr 7, 2023
Yes, that is my impression as well. The commit is ScribeMD/slack-templates@e2d9df0. It currently matches
perf. Should it matchperf[!]?:instead?woile commentedon Apr 7, 2023
I think it might be this:
commitizen/commitizen/defaults.py
Line 84 in 378a428
We can be sure with a test probably
Kurt-von-Laven commentedon Apr 7, 2023
Sorry, yes, you are correct. I linked to the wrong line.
woile commentedon Apr 28, 2023
Confirmed, gonna submit a patch soon
fix(bump): better match for change_type when finding increment