GitVersion icon indicating copy to clipboard operation
GitVersion copied to clipboard

no-bump-message should take precedence over *-version-bump-message

Open jeanplevesque opened this issue 3 years ago • 8 comments

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-]*\\))?:"

jeanplevesque avatar Aug 24 '22 17:08 jeanplevesque

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?

asbjornu avatar Aug 24 '22 19:08 asbjornu

Why do you think no-bump-message should 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:

  1. People normally provide messages matching *-version-bump-message. If that's the default/normal scenario, then adding another that matches no-bump-message should take precedence (because it's not the default).
  2. People normally provide messages matching no-bump-message. If that's the default/normal scenario, then adding another that matches *-version-bump-message should 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.

jeanplevesque avatar Aug 25 '22 20:08 jeanplevesque

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?

asbjornu avatar Sep 12 '22 11:09 asbjornu

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! 😀

jeanplevesque avatar Sep 18 '22 02:09 jeanplevesque

Have you read the section on conventional commits in the documentation?

Yes! That's what I used to create my config.

jeanplevesque avatar Sep 20 '22 15:09 jeanplevesque

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 avatar Sep 20 '22 20:09 asbjornu

@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?

jeanplevesque avatar Sep 22 '22 00:09 jeanplevesque

Thanks! 🚀

jeanplevesque avatar Sep 26 '22 13:09 jeanplevesque

:tada: This issue has been resolved in version 6.0.0 :tada: The release is available on:

Your GitReleaseManager bot :package::rocket:

arturcic avatar Dec 22 '22 15:12 arturcic