release branch without commits

[Ozzian]

I was investigating why my master branch had "alpha" tag and I found out that I wasn't using --no-ff switch, but that is not all...

There release branch is getting its semver calculated from the previous tag. I've understood from the documentation that the release-branch will calculate its own "beta" versions by default. That is not the case when the release branch doesn't contain any commits.

Test case for this:

        /***
         * Every build tags the repository with GitVer.Semver. Full pipeline
         ***/ 
        using (var fixture = new EmptyRepositoryFixture())
        {
            fixture.Repository.MakeATaggedCommit("1.0.0"); // initial at master

            // simulate development work
            fixture.Repository.CreateBranch("develop"); 
            fixture.Checkout("develop");
            fixture.MakeACommit("Development commit");

            // tag the development branch
            var developmentVersion = fixture.GetVersion();
            developmentVersion.SemVer.ShouldBe("1.1.0-alpha.1");
            fixture.ApplyTag(developmentVersion.SemVer); 

            // prepare for release
            fixture.Repository.CreateBranch("release/2.0.0"); 
            fixture.Checkout("release/2.0.0");

            // no commits in the release branch

            // tag the release
            var releaseVersion = fixture.GetVersion();
            releaseVersion.SemVer.ShouldBe("2.0.0-beta.0"); // this fails (= 1.1.0-alpha.1)
            fixture.ApplyTag(releaseVersion.SemVer); // fatal error here

            //merge into master
            fixture.Checkout("master");
            fixture.MergeNoFF("release/2.0.0");
            var masterVersion = fixture.GetVersion();
            masterVersion.SemVer.ShouldBe("2.0.0");
        }

The line of code that is returning the "false" semver is here

Related issue: #1289

[Jericho]

@Ozzian I can confirm that I'm noticing the same behavior: GitVersion seems to miscalculate the version number on branches without commits. In this screenshot from AppVeyor, you can see that the version of my build on release/6.0.0 has been calculated as 5.1.0.alpha.21.

What's even more bizarre is that the previous build was alpha.42 and the latest build is alpha.21.

I'm using GitVersion.CommandLine version 5.0.0-beta2-97

[Jericho]

Looking at my build log (which is available here), I see the following two intriguing entries:

INFO [05/20/19 15:45:15:08] Skipping update of 'refs/remotes/origin/release/6.0.0' as it already matches the remote ref.
INFO [05/20/19 15:45:15:08] HEAD points at branch 'refs/heads/develop'.

[Jericho]

@Ozzian I notice that in your unit test you are tagging your latest commit. I think this might explain why GitVersion is not calculating the version as you expect. From the Tags override other rules section in documentation:

If a commit is tagged, then GitVersion will always use that version over any calculated versions. This is so if you rebuild a tag then the same version will be produced.

But that doesn't explain why the version is not calculated as expected in my scenario.

[Jericho]

I have another example:

As you can see, the build of branch release/0.56.0 is labeled as alpha instead of rc and to make maters worse, the alpha number has decreased from 41 to 27.

Here is my Gitversion.yml:

mode: ContinuousDelivery
branches:
  develop:
    regex: dev(elop)?(ment)?$
    mode: ContinuousDeployment
    tag: alpha
  hotfix:
    regex: hotfix(es)?[/-]
    mode: ContinuousDeployment
    tag: beta
  release:
    regex: release(s)?[/-]
    mode: ContinuousDeployment
    tag: rc
ignore:
  sha: []

[Jericho]

To emphasize the point, notice how GitVersion properly calculates the right version number when I push a commit to the release branch:

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.