Allow 'blacklisting' terms / limiting number of hits per commit

[NicolasIRAGNE]

Hello,

I am trying to set up this tool for a project because of its simplicity. However, I could'nt figure out if there was a way to blacklist terms.

For example, I wanted to have something such as this:

  minor:
    - "feature:"

However, when I want to add features to the project, I name my branch feature/xxxx and then merge it into develop, which will trigger the version bump, in addition to the commits. Even worse, I am using gitlab merge requests feature and the merge commits often contain text from previous commits. This results in even the smallest changes bumping the version by a disproportionate amout every time.

This is making the tool close to unusable for me and I think this is a quite common workflow.

What do you think ? What is the expected workflow ?

[lukaszraczylo]

Hi, thank you for opening this issue - it's definitely interesting especially with projects using the git-flow. I will definitely have a look at possible enhancement/mitigation within the next 48 hours 👍

Just to clarify, the version bump should:

• Ignore branches names as not applicable
• In case for example of minor: test and commit value testing testable tests it should increment the counter only once

If there are any other requests let me know - I'll take care of it over the weekend :)

[lukaszraczylo]

@NicolasIRAGNE could you please check now with the latest version ( 1.4.1 ) if the issue persists?

[NicolasIRAGNE]

Thanks a lot, will test in a bit with my repository and compare results :-)

[NicolasIRAGNE]

Alright I have been doing some testing and I can't really say if it is working or not because there are some other issues / things I do not understand yet.

How does the "DEFAULT" increment work? Is it set to simply increment patch on every commit ?

Consider the following situation:

With the following config:

force:
  major: 1
  minor: 0
  patch: 0
  commit: 202bfb6b0f30a0f8bc029f1d093d2de35870ce83 # This is current develop HEAD
wording:
  minor:
    - "add"

This is the output I get:

>semver-gen-1.4.1.exe generate -l -d
DEBUG:
---COMMITS BEFORE CUT---
[]

DEBUG: >>>> FOUND MATCH 853 3

DEBUG:
---COMMITS AFTER CUT---
[{202bfb6b0f30a0f8bc029f1d093d2de35870ce83 Nicolas IRAGNE <[email protected]> Remove git thing
2021-12-09 10:38:50 +0100 +0100} {255fe6562908abc8a7c1ccfa798f89adbb367fc2 Nicolas IRAGNE <[email protected]> add some stuff
2021-12-11 02:19:22 +0100 +0100} {347a27b7ad99d87f2bada259176bd3531c18cee6 Nicolas IRAGNE <[email protected]> Merge branch 'test' into develop
add some stuff

See merge request !43
2021-12-11 02:32:53 +0100 +0100}]

DEBUG: Forced versioning (MAJOR) 1

DEBUG: Incrementing patch (DEFAULT) on  Remove git thing | Semver: 1.0.1

DEBUG: Incrementing patch (DEFAULT) on  add some stuff | Semver: 1.0.2

DEBUG: Found match for  add | add

DEBUG: Incrementing minor (WORDING) on  add some stuff | Semver: 1.1.1

DEBUG: Incrementing patch (DEFAULT) on  Merge branch 'test' into develop
add some stuff

See merge request !43 | Semver: 1.1.2

DEBUG: Found match for  add | add

DEBUG: Incrementing minor (WORDING) on  Merge branch 'test' into develop
add some stuff

See merge request !43 | Semver: 1.2.1

SEMVER 1.2.1

There are a few things I can see that are not what I would expect:

• The commit that is set as 'base' (here develop HEAD) is processed during version computation
• Version patch is still incremented on WORDING hits
• Merge commit is processed (this could be resolved by having an option to exclude terms)

Simply adding one commit bumped the version to 1.2.1 when I expected it to bump to 1.1.0.

NB: This happens with the previous version as well. These are just issues I did not notice because I was trying on a bigger history and the output was hard to read.

What do you think ?

[lukaszraczylo]

Thank you so much - that was really helpful! I've done some extra coding and:

• excluded merge events from calculations as they're included in the respective commits
• added another feature which I've been thinking about for a while - with either flag -e or config force.existing: true the semver-gen will respect existing tagging in place and start calculations only going forward from the latest tag issued

[NicolasIRAGNE]

I think - and perhaps this should go into its own issue - it should be possible to have direct control on how the default incrementing works.

Something like this: (just a quick draft of how I would imagine it)

#Choose to process either merge commit OR all the commits instead. Useful in case of just wanting to increment the default branch everytime a MR is accepted.
only-merge-commits: true 
auto-increment:
  default: Minor
  base: 'develop'
  branches:
    - feature: Minor
    - fix: Patch
    - patch: Patch
    - refactor: Major
    - test: None

Something like this would allow the following behavior:

• Merging branch feature/cool_update onto base branch bumps the minor version
• Merging branch fix/fix onto base branch bumps the patch version
• In case of merging a branch like patch/fix : I think the prefix should take precedence
• Merging branch cool_branch should increment Minor
• Merging branch test or test/stuff does not do anything

And if we use

only-merge-commits: false

Then the rules apply to every commit except the merge commit instead, with the wording rule still applying.

However, these are not easy changes and this perhaps goes beyond the scope of your project as these use cases are not what you were going for in the first place. I have switched tools at the moment because we had an urgent need in production but will still watch development because this could be an interesting lightweight alternative to the more complex tools.

Thank you for taking the time to discuss :-) I would gladly help with some testing if you update it.

[lukaszraczylo]

It's a really good idea but will require a bit of code reshuffling - yet, I am happy to take care of it but definitely not this weekend :) By the way - if you'd like to disable auto-increment on every commit you can enable strict mode which then will bump the patch version only keyword match

[NicolasIRAGNE]

Oh, interesting, I thought strict mode meant stricter matching on the wording (like disabling fuzzy).

[lukaszraczylo]

No, it essentially disables the automatic incrementation on every patch and triggers increments only if matched strings are detected. I'll make it more clear in the documentation :)

[joonalaine]

Hi, so just to be clear. Setting strict to false will auto increment patch if no keyword matches in the commit message?

[lukaszraczylo]

@joonalaine yes, exactly. For example - if your commit brings some changes, and your pipeline builds the docker container which you'd like to test - you can test it whilst making sure ( different tag due to bumped patch ) that it is what you wanted to test. Personally, I'm not getting too attached to the patch versions, and neither does google for example with their versioning ( 112.0.5615.40 for Chrome at the moment ), it's major and minor, which are of interest :)

[joonalaine]

Thanks!