Hotfix branch is not increasing Patch

[roofiq]

Hello,

I am using version 5.5. I want to implement semantic versioning to my GitFlow. I got quite a lot of errors but have managed to work it out - the documentation is really poor.
Still I can't manage to achieve one thing. On bugfixing situation, when I am creating new branch from master, it should have increased patch number - i.e. master is 1.0.0, so the hotfix/test should be 1.0.1 but it is 1.0.0.

I can achieve above when I am adding comment '+semver: patch'.
Then, when I want to create 2nd patch, the version is not increasing at all (even with the comment).
How it should work in this scenario?
Here is mine GitVersion file.

next-version: 2.0.0
branches:
  master:        
    regex: master
    mode: ContinuousDelivery
    tag: ''    
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    tracks-release-branches: false
    is-release-branch: false
   hotfix:
    tag: beta
    mode: ContinuousDelivery
    regex: ^hotfix(es)?[/-]
    increment: Patch
    prevent-increment-of-merged-branch-version: false
    track-merge-target: false
    tracks-release-branches: false
ignore:
  sha: []
merge-message-formats: {}

Thanks,
Rafal

[asbjornu]

As described in #2441, next-version doesn't seem to work well with commit message incrementing anymore. If you remove next-version and instead add a git tag 2.0.0 on the appropriate commit, what happens?

[senritsu]

We have a similar issue, but without using next-version (in fact even with an empty GitVersion.yml).

For some reason GitVersion completely ignores all hotfix merges. It does find one of 3 existing merges (and 3 times at that), but it does not increment at all:

INFO [04/01/21 10:48:06:28] Running against branch: master (fa43b09 Merge branch 'hotfix/gitversion-config')
INFO [04/01/21 10:48:06:28] Begin: Calculating base versions
  INFO [04/01/21 10:48:06:33] Fallback base version: 0.1.0 with commit count source 9a8dbe6583dff424ec8a6dc5a94c27f7f5e1498f
  INFO [04/01/21 10:48:06:37] Found commit [fa43b09 Merge branch 'hotfix/gitversion-config'] matching merge message format: Default
  INFO [04/01/21 10:48:06:38] Found commit [fa43b09 Merge branch 'hotfix/gitversion-config'] matching merge message format: Default
  INFO [04/01/21 10:48:06:38] Found commit [fa43b09 Merge branch 'hotfix/gitversion-config'] matching merge message format: Default
  INFO [04/01/21 10:48:06:43] Merge message 'Merge branch 'release/1.1'': 1.1.0 with commit count source c5723bd71e9aea4984dd4c6fc53f744aef558089
  INFO [04/01/21 10:48:06:43] Merge message 'Merge branch 'release/1.0'': 1.0.0 with commit count source 8b07fcb01e9d408523bbe11498d4da336f4123e3
  INFO [04/01/21 10:48:06:43] Merge message 'Merge branch 'release/1.0' into development': 1.0.0 with commit count source 292fa8e68e2230e7c7304e1c4b8d454bb9947be6
  INFO [04/01/21 10:48:06:63] Found multiple base versions which will produce the same SemVer (1.1.0), taking oldest source for commit counting (Merge message 'Merge branch 'release/1.1'')
  INFO [04/01/21 10:48:06:63] Base version used: Merge message 'Merge branch 'release/1.1'': 1.1.0 with commit count source f7e37a889bac64f3032ba98020e85587b9ae0862
  INFO [04/01/21 10:48:06:63] End: Calculating base versions (Took: 342.58ms)
  INFO [04/01/21 10:48:06:64] 37 commits found between f7e37a8 Merge branch 'feature/REDACTED' into development and fa43b09 Merge branch 'hotfix/gitversion-config'
  INFO [04/01/21 10:48:06:64] Skipping version increment
  INFO [04/01/21 10:48:06:65] 37 commits found between f7e37a8 Merge branch 'feature/REDACTED' into development and fa43b09 Merge branch 'hotfix/gitversion-config'

• the feature branch merge was just before the merge of release/1.0
• after release/1.1 there were 3 hotfixes merged into master

EDIT: using GitVersion.Tool 5.6.6 and 5.6.7

[asbjornu]

Are you able to reproduce this problem in a test, @senritsu? Look at this this for an idea how to write one:

GitVersion/src/GitVersion.Core.Tests/IntegrationTests/HotfixBranchScenarios.cs

Lines 15 to 48 in 557e96a

	[Test]
	// This test actually validates #465 as well
	public void PatchLatestReleaseExample()
	{
	using var fixture = new BaseGitFlowRepositoryFixture("1.2.0");
	// create hotfix
	Commands.Checkout(fixture.Repository, MainBranch);
	Commands.Checkout(fixture.Repository, fixture.Repository.CreateBranch("hotfix-1.2.1"));
	fixture.Repository.MakeACommit();
	fixture.AssertFullSemver("1.2.1-beta.1+1");
	fixture.Repository.MakeACommit();
	fixture.AssertFullSemver("1.2.1-beta.1+2");
	fixture.Repository.ApplyTag("1.2.1-beta.1");
	fixture.AssertFullSemver("1.2.1-beta.1");
	fixture.Repository.MakeACommit();
	fixture.AssertFullSemver("1.2.1-beta.2+3");
	// Merge hotfix branch to main
	Commands.Checkout(fixture.Repository, MainBranch);
	fixture.Repository.MergeNoFF("hotfix-1.2.1", Generate.SignatureNow());
	fixture.AssertFullSemver("1.2.1+4");
	fixture.Repository.ApplyTag("1.2.1");
	fixture.AssertFullSemver("1.2.1");
	// Verify develop version
	Commands.Checkout(fixture.Repository, "develop");
	fixture.AssertFullSemver("1.3.0-alpha.1");
	fixture.Repository.MergeNoFF("hotfix-1.2.1", Generate.SignatureNow());
	fixture.AssertFullSemver("1.3.0-alpha.5");
	}

[senritsu]

Yes, I can reproduce it on freshly checked out main.

All existing integration tests in HotfixBranchScenarios.cs pass just fine. This new one doesn't:

        [Test]
        public void HotfixMergeIncrementsVersion()
        {
            using var fixture = new EmptyRepositoryFixture();

            // initialize gitflow

            const string devBranch = "develop";

            fixture.Repository.MakeACommit("setup repo");
            fixture.Repository.CreateBranch(devBranch);
            Commands.Checkout(fixture.Repository, devBranch);

            // make some changes on dev

            fixture.Repository.MakeACommit("add stuff");
            fixture.Repository.MakeACommit("add more stuff");

            // make a release

            const string releaseBranch = "release/1.0";

            fixture.Repository.CreateBranch(releaseBranch);
            Commands.Checkout(fixture.Repository, releaseBranch);
            fixture.Repository.MakeACommit("fix some minor thing");

            fixture.AssertFullSemver("1.0.0-beta.1+1"); // PASS

            Commands.Checkout(fixture.Repository, MainBranch);
            fixture.Repository.MergeNoFF(releaseBranch, Generate.SignatureNow());

            fixture.AssertFullSemver("1.0.0+0"); // PASS

            // make a hotfix

            const string hotfixBranch = "hotfix/something-important";
            // const string hotfixBranch = "hotfix/1.0.1"; // this also fails in the exact same manner
            // const string hotfixBranch = "hotfix-1.0.1"; // this as well

            fixture.Repository.CreateBranch(hotfixBranch);
            fixture.Repository.MakeACommit("fix the important issue");
            // fixture.AssertFullSemver("1.0.1-beta.1+1"); // FAIL, version is 1.0.0+1

            Commands.Checkout(fixture.Repository, MainBranch);
            fixture.Repository.MergeNoFF(hotfixBranch, Generate.SignatureNow());

            fixture.AssertFullSemver("1.0.1+1"); // FAIL, version is 1.0.0+1
        }

I tried making it as minimal as possible, and judging from the other tests (especially PatchLatestReleaseExample, specifically the assert in L25 before tagging) this should work, unless I overlooked something crucial.

[senritsu]

With the addition of

            fixture.ApplyTag("1.0");
            fixture.AssertFullSemver("1.0.0");

after merging the release, the whole test passes.

This makes things even more strange, since in our production setup we do actually have tagged releases in this manner, and it still fails. Additionally the versioning of main works correctly even without a tag, so it leads to believe the tag is optional.

[senritsu]

Interestingly enough, uncommenting the assert on the hotfix branch after committing but before merging

fixture.AssertFullSemver("1.0.1-beta.1+1"); // FAIL, version is 1.0.0+1

still fails, because the version at that point is, even with a tagged release, 1.0.1+1. This does contrast with the asserts in PatchLatestReleaseExample, where the beta prerelease tag is correctly applied.

Tangentially related: The error message when using fixture.Repository.MergeNoFF with a non-existing branch is kind of misleading. It bubbles the internal exception about the branch name being null (System.ArgumentNullException : Value cannot be null. (Parameter 'branch')) despite MergeNoFF receiving a non-null branch name.

[asbjornu]

This is all very weird. Sorry for not having time to figure out the source of this problem yet. If you're able to submit a PR with the failing test, perhaps you or someone else can pick it up and figure out a fix later.

[senritsu]

Using GitVersion.MSBuild 5.7.0, with further investigation we have very confusing results.

The setup is a solution with 2 projects, last release 0.5, and 7 merged hotfixes on top. Correct version should therefore probably be 0.5.7.

A local build results in 0.5.1

REDACTED>dotnet build -c Release
Microsoft (R) Build Engine version 16.11.0+0538acc04 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  REDACTED -> REDACTED\bin\Release\netstandard2.0\REDACTED.dll
  Successfully created package 'REDACTED\bin\Release\REDACTED.0.5.1.nupkg'.
  REDACTED -> REDACTED\bin\Release\netstandard2.0\REDACTED.dll
  Successfully created package 'REDACTED\bin\Release\REDACTED.0.5.1.nupkg'.

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:05.60

A CI build in GitLab CI run inside the mcr.microsoft.com/dotnet/sdk:5.0 docker image results in 0.5.0

$ dotnet build -c Release
Microsoft (R) Build Engine version 16.11.0+0538acc04 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
  Determining projects to restore...
  Restored /builds/REDACTED.csproj (in 4.58 sec).
  Restored /builds/REDACTED.csproj (in 4.58 sec).
  REDACTED -> /builds/REDACTED/bin/Release/netstandard2.0/REDACTED.dll
  Successfully created package '/builds/REDACTED/bin/Release/REDACTED.0.5.0.nupkg'.
  REDACTED -> /builds/REDACTED/bin/Release/netstandard2.0/REDACTED.dll
  Successfully created package '/builds/REDACTED/bin/Release/REDACTED.0.5.0.nupkg'.
Build succeeded.
    0 Warning(s)
    0 Error(s)
Time Elapsed 00:00:10.59

At first I thought the local build worked correctly (as mentioned in #2847), but apparently it only increments patch version for exactly one hotfix.

[asbjornu]

Version numbers below 1.0.0 are, for some reason, a bit problematic for GitVersion. Try bumping to 1.0.0 with a git tag and see if that changes the behavior.

[PilotBob]

I wanted to saw we are seeing this issue still. It didn't increment Patch in a git flow created hotfix branch. It calculated the same version as if it was running in master (our mainline branch).

As a workaround I added a tag to the hotfix branch matching the hotfix name. But, afaict that should be necessary. This happened with an older version (on build server) and I duplicated it with 5.10 on my dev machine.

This had worked on other hotfix branches. Not sure what is/was different.

[asbjornu]

@PilotBob, what was the name of the hotfix branch? Also, are you using next-version?

[PilotBob]

@PilotBob, what was the name of the hotfix branch? Also, are you using next-version?

hotfix/2022.05.01

We do have a next-version in our .yml file. But it's been there forever. (Well not forever, since we changed from sequential version numbers to date based. So use next-version to go from 11.1.0 to 2021.10.00 version.)

After I saw this thread I took it out in the branch, but it didn't seem to make a difference.

[PilotBob]

@asbjornu So did a bit more fiddling. It seems that the version calculated in the hotfix branch only increments the patch value is there is a commit in the hotfix branch.

So, it my test I did.

git flow hotfix start 2022.05.01

In the hotfix branch gitversion calculated 2022.5.0.

I added a file, and committed... and then after that it calculated 2022.5.1. So, while not expected, it seems to be working. I just have to remember this for the next time we do a hotfix. :)

[asbjornu]

Great. Closing this as a workaround has been found, then.

[HHobeck]

As described in #2441, next-version doesn't seem to work well with commit message incrementing anymore. If you remove next-version and instead add a git tag 2.0.0 on the appropriate commit, what happens?

Is this maybe a bug? @asbjornu

[asbjornu]

@HHobeck, I believe it is, yes.