Version not bumped if an irrelevant tag exists in latest commit

[adaskos-signal]

Hi all.
I'm trying to understand if this is a bug or I'm missing something.
When a tag exists in the latest commit, GitVersion will not parse the commit message and bump version according to the rules.

Minimal steps to reproduce:
(assuming a git repo which currently calculates version as 1.0.0)
Add a bumping commit:

git commit --allow-empty -m "+semver: major"

Now dotnet gitversion /showvariable semver will give the correct version (2.0.0)

If I first tag the commit:

git tag "BLAH"

the same command will give me version 1.0.1 although the tag has no semantic versioning.

This has implications in our CI build and I don't believe it's the expected behavior.

[adaskos-signal]

I believe this is related to #3071 and FindCommitMessageIncrement. Any tag will stop the search for increments, when it should only consider ValidVersionTags based on tag prefix.

[adaskos-signal]

I'm not at ease with contributing to a project and it would take me some time to understand all the various parts of GitVersion, but if it helps I wrote a unit test, inside VersionBumpingScenarios.cs:

[Test]
public void CanUseCommitMessagesToBumpVersion_TagDoesNotTakePriorityIfNotAVersion()
{
    using var fixture = new EmptyRepositoryFixture();
    var repo = fixture.Repository;

    repo.MakeATaggedCommit("1.0.0");
    repo.MakeACommit("+semver:major");
    fixture.AssertFullSemver("2.0.0+1");

    repo.ApplyTag("NotAVersion");
    fixture.AssertFullSemver("2.0.0+1");

    repo.MakeACommit();
    fixture.AssertFullSemver("2.0.0+2");
}

I could make it pass - without breaking any of the existing tests - by using an IRepositoryStore repositoryStore inside IncrementStrategyFinder and then used the following inside FindCommitMessageIncrement:

var tags = new HashSet<string?>(
        //only commits with valid version tag should be considered (see #3757)
        this.repositoryStore.GetValidVersionTags(context.FullConfiguration.TagPrefix)
            .Select(x => x.Tag)
    .Select(t => t.TargetSha));

But other than that I cannot tell if it has any performance implications, or if it covers the rest of the cases/tools/build tasks/etc.
I'm just trying to help in hope of a quick fix 😇

[HHobeck]

Hi @adaskos-signal .

Thank you for providing such detail information. In my opinion you are on the right track. Please provide a PR to fix this issue based on the main branch. In advance I want to tell you that we are in development phase and just releasing beta versions at this moment. Performance is something we need to address at the end of the development phase.

Cheers

[adaskos-signal]

Any chance this will end in the 5.x support branch too?

[arturcic]

branch 5.x is now readonly, we won't release any new version from the 5.x

[adaskos-signal]

I created a PR #3759 for this.

[Sefriol]

@adaskos-signal in my case the "irrelevant" tag is actually an alpha release from dev since we use rebase fast forward when merging from dev to main. Would your PR be relevant to this issue as well?

[Sefriol]

Expected:

%%{init: { 'gitGraph': {'rotateCommitLabel': false, 'chartOrientation': 'horizontal' }} }%%
 gitGraph
    commit id: "init"
    branch dev
    branch feature
    commit id: "feat: 1"
    commit id: "feat: 2"
    commit id: "feat: 3"
    checkout dev
    merge feature id: "rebase+merge" tag: "v0.1.0-alpha.3"
    checkout main
    merge dev id: "rebase fastforward" tag: "v0.1.0, v0.1.0-alpha.3"

Loading

Actual:

%%{init: { 'gitGraph': {'rotateCommitLabel': false, 'chartOrientation': 'horizontal' }} }%%
 gitGraph
    commit id: "init"
    branch dev
    branch feature
    commit id: "feat: 1"
    commit id: "feat: 2"
    commit id: "feat: 3"
    checkout dev
    merge feature id: "rebase+merge" tag: "v0.1.0-alpha.3"
    checkout main
    merge dev id: "rebase fastforward" tag: "v0.1.0-alpha.3"

Loading

@HHobeck @arturcic Just ensuring from my previous question: would following interaction be also fixed in the new release?

Currently GitVersion won't add a new tag to main branch merge if it does not generate a new commit. We use Rebase Fast Forward strategy when adding commits to main.

[HHobeck]

Hi @Sefriol.

I don’t understand why your scenario should be related to this issue. In your case the commit on main (which is the same on develop because of rebase fast forward) is marked with the tag v0.1.0 and v0.1.0-alpha.3. GitVersion takes the highest tag which is in your case v0.1.0. Thus the resulting version on main and on develop would be 0.1.0 which is the common behavior independent of this fix.

Regards
Hardy

[Sefriol]

I am using the 5.x version and it does not add tag v0.1.0 when dev branch is merged to main.

EDIT: To clarify: main and dev are in same commit id, but running gitversion yields same tag. Only when tagless commit is added to main, v0.1.0 tag is added.

EDIT2: It could be that my config is just incorrect for what I am trying to do. If you have an example of what I should be using, I am all ears. :)

[HHobeck]

I am using the 5.x version and it does not add tag v0.1.0 when dev branch is merged to main.

GitVersion doesn't add tags add all. This is something which is left to the user.

EDIT: To clarify: main and dev are in same commit id, but running gitversion yields same tag. Only when tagless commit is added to main, v0.1.0 tag is added.

GitVersion doesn't yield tags it yields semantic versions. You cannot add tags on a specific branch. You only add tags on a commit which can be part of one, two (like in your case) or more branches. What I'm trying to say is if you tag it on main then it is also visible on dev branch for the same commit (that's the way how git works).

EDIT2: It could be that my config is just incorrect for what I am trying to do. If you have an example of what I should be using, I am all ears. :)

What are you trying to do?

[HHobeck]

Maybe this feature is something you are interested in:

• [Feature] Same version computed on different branches #3453

[Sefriol]

I remembered incorrectly that gitversion add tags. Anyway, it uses git tags to determine the next proper version and does not do it properly if some incorrect tag exists (as per subject of this issue).

Anyway, let's go over my process step by step:

1. Feature branch is merged to dev. This adds a merge commit and I use dotnet-gitversion /showvariable SemVer in a pipeline and add the result as a tag to the merge commit.
2. We decide to release this version, and we generate a merge request. Request is then merged to main using rebase fast forward. This does not generate a new commit.
3. Pipeline tries to generate a new tag using dotnet-gitversion /showvariable SemVer. Since commit already has a tag, it gives out the same tag (v0.1.0-alpha.3). This is not what I want. I want additional, correct, tag to be created (v0.1.0).

This would work if a new commit without any tag is added to the main branch.

The reason I reference this issue is that I consider v0.1.0-alpha.3 to be correct version tag, but not for main branch and therefore should not be used for the version calculation. Not sure if I explained this correctly.

EDIT: Or could I achieve the same using Mainline mode? I am little uncertain how I should configure GitVersion.

[HHobeck]

The reason I reference this issue is that I consider v0.1.0-alpha.3 to be correct version tag, but not for main branch and therefore should not be used for the version calculation. Not sure if I explained this correctly.

In the upcoming version of gitversion (6.x.x) we have changed the meaning of mode which might be useful for you. Please take a look to this discussion:

• Release branches are treated as pre-releases #3906

Just a side note: You have specified on the main branch the label property to null. That means gitversion considers all pre-released version. If you remove this tag the result will be 0.1.0-X. Please take a look to the following integration tests to get an understanding how it works:

• GitVersion/src/GitVersion.Core.Tests/IntegrationTests/OtherScenarios.cs

  Line 258 in d878181

  public void EnsurePreReleaseTagLabelWithInitialTagForPatchNumberOneWillBeConsideredIfNoLabelIsDefined()

• GitVersion/src/GitVersion.Core.Tests/IntegrationTests/OtherScenarios.cs

  Line 393 in d878181

  public void EnsurePreReleaseTagLabelWillBeConsideredIfLabelIsEmpty(long patchNumber)

[Sefriol]

Hmm, yeah. It might do it. Not entirely sure. I think I will just fix it for now by using MajorMinorPatch-variable instead when pipeline runs in main branch.

[arturcic]

🎉 This issue has been resolved in version 6.0.0-beta.6 🎉
The release is available on:

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot 📦🚀