Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jeanplevesque opened this issue Aug 24, 2022 · 10 comments · Fixed by #3202
Closed

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

jeanplevesque opened this issue Aug 24, 2022 · 10 comments · Fixed by #3202

Comments

@jeanplevesque
Copy link
Contributor

jeanplevesque commented Aug 24, 2022

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-]*\\))?:"
@asbjornu
Copy link
Member

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?

@jeanplevesque
Copy link
Contributor Author

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.

@asbjornu
Copy link
Member

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?

@jeanplevesque
Copy link
Contributor Author

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

@asbjornu
Copy link
Member

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

@jeanplevesque
Copy link
Contributor Author

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

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

@asbjornu
Copy link
Member

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.

@jeanplevesque
Copy link
Contributor Author

jeanplevesque commented Sep 22, 2022

@asbjornu I've created this draft PR #3202 to start the conversation.
I'm assuming the target branch is incorrect if this changed is aimed toward v6?

@asbjornu asbjornu added this to the 6.x milestone Sep 23, 2022
@jeanplevesque
Copy link
Contributor Author

Thanks! 🚀

@arturcic arturcic modified the milestones: 6.x, 6.0.0-alpha.1 Dec 22, 2022
@arturcic
Copy link
Member

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

Your GitReleaseManager bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants