GitVersion
GitVersion copied to clipboard
no-bump-message should take precedence over *-version-bump-message
Detailed Description
It seems like when both no-bump-message and *-version-bump-message are matched, the version bump wins.
Is that the intended behavior?
Context
I configured the *-version-bump-message to follow conventional commits.
I would like that if I add +semver: skip to a conventional commit, the version isn't incremented.
Basically, the following commit currently increments the version and that's not what I want.
ci: Some commit message
+semver: skip
Here's my config:
assembly-versioning-scheme: MajorMinorPatch
mode: MainLine
next-version: '' # Use git tags to set the base version.
continuous-delivery-fallback-tag: ""
commit-message-incrementing: Enabled
major-version-bump-message: "^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test)(\\([\\w\\s-]*\\))?(!:|:.*\\n\\n((.+\\n)+\\n)?BREAKING CHANGE:\\s.+)"
minor-version-bump-message: "^(feat)(\\([\\w\\s-]*\\))?:"
patch-version-bump-message: "^(build|chore|ci|docs|fix|perf|refactor|revert|style|test)(\\([\\w\\s-]*\\))?:"
branches:
master:
regex: ^master$|^main$
tag: ''
ignore:
sha: []
Workaround
Although this isn't a perfect solution, we've decided that the "ci" conventional commit type would not bump the version.
We've changed our configuration as such:
patch-version-bump-message: "^(build|chore|docs|fix|perf|refactor|revert|style|test)(\\([\\w\\s-]*\\))?:"
no-bump-message: "^(ci)(\\([\\w\\s-]*\\))?:"
I'm not sure the precedence *-version-bump-message takes over no-bump-message is conscious or accidental. Either way, I think it can be argued as strongly for either taking precedence over the other. I'm not sure the current behavior is wrong. Why do you think no-bump-message should take precedence?
Why do you think
no-bump-messageshould take precedence?
Mainly intuition to be honest. I just thought that would be the behavior.
Reasoning
What is expected when enabling commit-message-incrementing? I'm comparing two scenarios:
- People normally provide messages matching
*-version-bump-message. If that's the default/normal scenario, then adding another that matchesno-bump-messageshould take precedence (because it's not the default). - People normally provide messages matching
no-bump-message. If that's the default/normal scenario, then adding another that matches*-version-bump-messageshould take precedence (because it's not the default).
Scenario 2 is the current behavior. In my opinion, it seems strange that the normal behavior would be to provide messages matching no-bump-message.
As I'm not a user of commit-message-incrementing myself, please answer me this: Would you enforce a no-bump-message or *-version-bump-message in every commit across all branches? Can you please explain your workflow in a bit more detail?
I'm enforcing the usage of conventional commits.
Knowing that, the version is driven by the conventional commit message type (fix, feat, chore, docs, (...), and the presence of ! or BREAKING CHANGE:).
Examples:
| Commit Message | Version Increment |
|---|---|
fix: Some bugfix. |
Patch |
docs: Improve XML documentation. |
Patch |
feat: Add some feature. |
Minor |
feat!: Change some public API. |
Major |
fix!: Fix incoherence with API contract. |
Major |
To answer your question: using this, all commits across all branches match *-version-bump-message.
Now in some cases, I would like to be able to specify no increment (because not all code in the repository is for the actual product).
Here are some examples.
chore: Adjust .editorconfig for coding convention.
+semver: skip
ci: Add some GitHub actions.
+semver: skip
docs: Improve GitHub documentation.
+semver: skip
Let me know if you'd like more details! 😀
Have you read the section on conventional commits in the documentation?
Have you read the section on conventional commits in the documentation?
Yes! That's what I used to create my config.
Right. Thanks for providing the examples, that clears things up. When combining conventional commits with no-bump-message, I can definitely see how reversing the precedence of *-version-bump-message and no-bump-message makes sense. If you want to provide a PR, this change is something we can prime for v6.
@asbjornu I've created this draft PR https://github.com/GitTools/GitVersion/pull/3202 to start the conversation. I'm assuming the target branch is incorrect if this changed is aimed toward v6?
Thanks! 🚀
:tada: This issue has been resolved in version 6.0.0 :tada: The release is available on:
Your GitReleaseManager bot :package::rocket: