getNextSemanticVersion ignores latest Git tag

[kobmik]

Jenkins and plugins versions report

Environment

Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?

Linux

Reproduction steps

We would like to generate the next version with the method getNextSemanticVersion().
Somehow, the plugin doesn't recognize the already set Git tag. In this example the tag 7.0.0 (master branch) is set and a new commit "fix: test" was pushed to the develop branch.

getNextSemanticVersion(majorPattern: 'BREAKING CHANGE', minorPattern: '^feat', patchPattern: '^fix')

getHighestSemanticVersion is resulting in 0.0.0
getNextSemanticVersion is resulting in 0.1.0

Expected Results

The method should return the version 7.0.1

Actual Results

[Pipeline] getHighestSemanticVersion
[Pipeline] getNextSemanticVersion
[Pipeline] sh
+ git tag
7.0.0
[Pipeline] echo
nextVersion:0.1.0
[Pipeline] echo
highestVersion:0.0.0

Anything else?

No response

[tomasbjerre]

And the commit tagged with 7.0.0 in the master branch is a parent of the development branch?

[tomasbjerre]

Are you doing "git tag" after or before calculating next version? Looks like you might be doing it after? You should do it before.

[kobmik]

I created the commits on the dev branch and then merged them to the master branch. Afterwards I started the pipeline for the master branch which created the Git tag 7.0.0 at the end. Now I'm creating new commits on the dev branch, but nextVersion doesn't recognize the latest tag on the master branch and returns me 0.1.0 as next version in the pipeline.

I'm doing git tag before calculating the next version.

[tomasbjerre]

Ok sounds like you are calculating the next version on dev without having merged master to dev (dev not having latest version as a parent).

And that is how the plugin works, it calculates based on the parents.

[kobmik]

That seems to work. But this was only a test case. Normally we use gitflow workflow and therefore never merge the master branch back to dev. The release branch will be merged to master and then back to dev.
Is there a chance for an option to take all tags into account for generating the next version?

[tomasbjerre]

No there is no such option.

Can you not merge master to dev after merge of release to master?

Or create the tag in the release branch so that the tag gets merged to dev and master.

The reason for doing it this way is to enable release-branches where versions are patched. So that you can do a hotfix and calculate next version based on whatever version you are patching.

[kobmik]

Thanks for your suggestions. We would like to calculate the next version during the build of the master branch and tag the commit only if the build was successful. Merging master to dev might be an option, but then we have to ensure, that master will immediately be merged back to developer. Otherwise subsequent builds will calculate a wrong version numbers. As soon as we have multiple open branches, we have to merge master back to all branches. Otherwise same problem with wrong calculated versions.

Do you see a possibility, to add our requested behaviour to the plugin (with an option flag) in a future release?

[tomasbjerre]

I dont understand your use case. You would have to supply some scenarios and what you want to achieve in those scenarios.

[kobmik]

We do our branching according Gitflow.
Right now we are trying to switch to Maven CI friendly versions and therefore we would also like to calculate the next version from the projects conventional commits.

Example Gitflow:
feature -> develop -> release -> master

After a PR from release to master, we build the master version, tag the commit with the calculated version and then deploy it to production.
Now the release branch gets merged back to develop. As long as master never gets merged back to develop or already new feature branches have been created in the meantime, the versioning doesn't work properly anymore for these branches. They would get again the same version as the master branch even if they have already some feat or fix commits.

To solve this, the plugin should take all tags into account regardless of whether they have been merged back to dev branches or not.

Hope this explains our plan/problem :-)

[tomasbjerre]

We do our branching according Gitflow. Right now we are trying to switch to Maven CI friendly versions and therefore we would also like to calculate the next version from the projects conventional commits.

Example Gitflow: feature -> develop -> release -> master

After a PR from release to master, we build the master version, tag the commit with the calculated version and then deploy it to production.

At this point you have no problems right? Because master is tagged with previous release so this new release is based in the old one and gets new correct version.

Now the release branch gets merged back to develop. As long as master never gets merged back to develop or already new feature branches have been created in the meantime, the versioning doesn't work properly anymore for these branches. They would get again the same version as the master branch even if they have already some feat or fix commits.

Why do you need a new version here? Do you want to set snapshot-versions based on conventional commits?

To solve this, the plugin should take all tags into account regardless of whether they have been merged back to dev branches or not.

I dont see how that logic should work. Getting the highest tag is easy. But to calculate next version we need to know what will be included in the new release, and parse their commit messages. We can answer that question by merging to develop and calculate the next version on develop.

Hope this explains our plan/problem :-)

[kobmik]

Calculating version for master branch is no problem.
Yes, we would also like to generate next snapshot versions based on conventional commits.

I see your point. Its very difficult/impossible to have a generic logic for this. What about implementing an option for getNextSemanticVersion where we can set our starting commit? And for getHighestSemanticVersion a flag to return the latest tag overall?

[tomasbjerre]

I released 3.31 and it adds from/to config to getHighestSemanticVersion.

I think maby this can work for you:

node {
    sh """
    rm -rf *
    git clone [email protected]:jenkinsci/git-changelog-plugin.git .
    """
    
    def theCurrentBranch = "develop, feature/x or whatever..."
    
    def highestSemanticVersion = getHighestSemanticVersion(
        to: [type: 'REF', value: 'master'])

    def fromTag = highestSemanticVersion.findTag().orElse("");

    println "Getting version from ${fromTag} to ${theCurrentBranch}"

    def nextVersion = getNextSemanticVersion(
        from: [type: 'REF', value: fromTag],
        to: [type: 'REF', value: theCurrentBranch],
        majorPattern: 'BREAKING CHANGE',
        minorPattern: '^feat',
        patchPattern: '^fix')
        
    println "Next version:" + nextVersion.toString();
    println " Major:" + nextVersion.getMajor();
    println " Minor:" + nextVersion.getMinor();
    println " Patch:" + nextVersion.getPatch();
}

[kobmik]

Thanks for adding this new feature! Looks promising. Unfortunately, I'm on holydays the coming three weeks and can't test it. Will do it afterwards and give you a feedback.

[kobmik]

I now had the time to test your new option flags. Unfortunatelly, getNextSemanticVersion still doesn't work as expected. Is it still necessary to merge master to our develop branch to generate the next version?

Our branch network looks like this right now:

With the following call I would expect, that the method should return 7.1.1 as next version if a have a single commit with "feat: ...". Am I wrong?

getNextSemanticVersion( from: [type: 'REF', value: '7.1.0'], to: [type: 'REF', value: 'develop'], majorPattern: 'BREAKING CHANGE', minorPattern: '^feat', patchPattern: '^fix' )

[tomasbjerre]

Try with the regexp from readme:

def nextVersion = getNextSemanticVersion from: [type: 'REF', value: '7.1.0'], to: [type: 'REF', value: 'develop'], 
    majorPattern: '^[Bb]reaking.*',
    minorPattern: '^[Ff]eature.*',
    patchPattern: '^[Ff]ix.*'

[kobmik]

Same behaviour. getNextSemanticVersion generates version 0.1.0 instead of 7.1.1 or 7.2.0.

[tomasbjerre]

I also made a test and can confirm that it does not work.

If I do it like you did:

*   bd7a59a - (tag: 7.1.0, master) Merge commit 'cc3eb86' (5 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
|\  
| | * 274f2fa - (HEAD -> develop) feat: some new feature (7 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| |/  
| * cc3eb86 - fix: something (7 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
|/  
* 2804e63 - init (8 minuter sedan) <Tomas Bjerre><Tomas Bjerre>

npx git-changelog-command-line --from-ref 7.1.0 --to-ref develop --print-next-version

Will give me 0.1.0.

And if I merge master to develop:

*   3835294 - (HEAD -> develop) Merge tag '7.1.0' into develop (4 sekunder sedan) <Tomas Bjerre><Tomas Bjerre>
|\  
| *   bd7a59a - (tag: 7.1.0, master) Merge commit 'cc3eb86' (18 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| |\  
* | | 274f2fa - feat: some new feature (20 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| |/  
|/|   
* | cc3eb86 - fix: something (21 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
|/  
* 2804e63 - init (22 minuter sedan) <Tomas Bjerre><Tomas Bjerre>

I will get 7.2.0.

I'm putting this issue on my TODO -list.

[jericop]

I faced a similar issue and it turned out to be caused by the way Jenkins does a checkout for a repo (in a multi-branch pipeline job). The only thing fetched is the branch being built, so there are no fetched tags that can be compared against. My solution is to fetch the latest tag from the remote (if one exists). Once that is done, the highest and next sermver methods are correct.

latest_tag=$(git ls-remote -q --symref --tags --sort='-version:refname' | head -1 | awk '{print $2}' | cut -d^ -f1 | cut -d/ -f3)
if [[ ! -z "$latest_tag" ]]; then
  git fetch origin "${latest_tag}"
  git tag "${latest_tag}" FETCH_HEAD
fi

Note that the solution above requires authentication with the remote.