-
-
Notifications
You must be signed in to change notification settings - Fork 33
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
getNextSemanticVersion ignores latest Git tag #84
Comments
And the commit tagged with 7.0.0 in the master branch is a parent of the development branch? |
Are you doing "git tag" after or before calculating next version? Looks like you might be doing it after? You should do it before. |
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. |
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. |
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. |
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. |
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? |
I dont understand your use case. You would have to supply some scenarios and what you want to achieve in those scenarios. |
We do our branching according Gitflow. Example Gitflow: 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. 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 :-) |
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.
Why do you need a new version here? Do you want to set snapshot-versions based on conventional commits?
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.
|
Calculating version for master branch is no problem. 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? |
I released 3.31 and it adds I think maby this can work for you: node {
sh """
rm -rf *
git clone git@github.com: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();
} |
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. |
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?
|
Try with the regexp from readme:
|
Same behaviour. getNextSemanticVersion generates version 0.1.0 instead of 7.1.1 or 7.2.0. |
I also made a test and can confirm that it does not work. If I do it like you did:
npx git-changelog-command-line --from-ref 7.1.0 --to-ref develop --print-next-version Will give me And if I merge
I will get I'm putting this issue on my TODO -list. |
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.
Note that the solution above requires authentication with the remote. |
Jenkins and plugins versions report
Environment
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
The text was updated successfully, but these errors were encountered: