[Bug] tag: '' doesn't strip the alpha tag in master branch

[alsterg]

Describe the bug
According to documentation (and my understanding) GitVersion's default config should strip the PreReleaseTag from the last known tag and give back a SemVer that can be released as the stable/final/ga version e.g. 1.0.0 as opposed to 1.0.0-alpha.1, which is what it returns instead.

Expected Behavior

GitVersion should strip the tag and give as SymVersion: "SemVer": "1.0.0"

Actual Behavior

GitVersion will return the next PreReleaseNumber increment for the latest tag, which includes the alpha string.

$ dotnet-gitversion  
{
  "Major": 1,
  "Minor": 0,
  "Patch": 0,
  "PreReleaseTag": "alpha.1",
  "PreReleaseTagWithDash": "-alpha.1",
  "PreReleaseLabel": "alpha",
  "PreReleaseLabelWithDash": "-alpha",
  "PreReleaseNumber": 1,
  "WeightedPreReleaseNumber": 55001,
  "BuildMetaData": null,
  "BuildMetaDataPadded": "",
  "FullBuildMetaData": "Branch.master.Sha.1dd37abed877c31aac774472949883a75332b96c",
  "MajorMinorPatch": "1.0.0",
  "SemVer": "1.0.0-alpha.1",
  "LegacySemVer": "1.0.0-alpha1",
  "LegacySemVerPadded": "1.0.0-alpha0001",
  "AssemblySemVer": "1.0.0.0",
  "AssemblySemFileVer": "1.0.0.0",
  "FullSemVer": "1.0.0-alpha.1",
  "InformationalVersion": "1.0.0-alpha.1+Branch.master.Sha.1dd37abed877c31aac774472949883a75332b96c",
  "BranchName": "master",
  "EscapedBranchName": "master",
  "Sha": "1dd37abed877c31aac774472949883a75332b96c",
  "ShortSha": "1dd37ab",
  "NuGetVersionV2": "1.0.0-alpha0001",
  "NuGetVersion": "1.0.0-alpha0001",
  "NuGetPreReleaseTagV2": "alpha0001",
  "NuGetPreReleaseTag": "alpha0001",
  "VersionSourceSha": "1dd37abed877c31aac774472949883a75332b96c",
  "CommitsSinceVersionSource": 0,
  "CommitsSinceVersionSourcePadded": "0000",
  "UncommittedChanges": 0,
  "CommitDate": "2022-10-05"
}

Possible Fix

Set a tag value to a non empty string e.g. tag: 'ga'

Steps to Reproduce

 $mkdir delme
 $cd delme/
 $git init
 $touch README
 $git add README 
 $git commit -m README
 $git tag 1.0.0-alpha.1
 $dotnet-gitversion

GitVersion.yml fragment:

....
  main:
    mode: ContinuousDelivery
    tag: ''
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    regex: ^master$|^main$
    source-branches:
    - develop
    - release
    tracks-release-branches: false
    is-release-branch: false
    is-mainline: true
    pre-release-weight: 55000
...

Context

This bug complicates our release process, as we need to code in our requirements by means outside of GitVersion.

• Version Used: 5.10.3+Branch.support-5.x.Sha.bc9c9d003e655385e3dd1ba3bd013e04062d2f9b
• Operating System and version (Windows 10, Ubuntu 18.04): RHEL 8
• Link to your project:
• Link to your CI build (if appropriate):

[lee-at-work]

Hi @alsterg, if you want to make a release has semver 1.0.0, create a git tag v1.0.0 to the main/master branch. Any untagged commits from main/master branch will leave you with a tag, depending what configuration you have on that branch.

Find out more with this parameter: -showconfig. dotnet-gitversion -showconfig
It shows you the complete configuration with the GitVersion.yml file merged as one.

[enriqueraso]

@asbjornu it will be fixed with changes done in #3224.

@alsterg you can run dotnet-gitversion /config GitVersion.yml /nofetch /nocache /verbosity Diagnostic /output buildserver to get more detail in how is calculating semver for your branch.

Same scenario happens to me. I tagged main branch with 1.14.0-rc and then I created a releases/1 branch. GitVersion returns 1.14-rc on this branch because it resolves from a branch with a tag, although I have an empty string tag for releases branch configuration.

[HHobeck]

May I ask you to reproduce your issue in a unit/integration test and give us your expectations?

    [Test]
    public void __Just_A_Test__()
    {
        var mainlineConfiguration = TestConfigurationBuilder.New
            .WithoutVersioningMode()
            .WithVersioningMode("release", VersioningMode.Mainline).WithTag("release", "").Build();
        var continuousDeploymentConfiguration = TestConfigurationBuilder.New
            .WithoutVersioningMode()
            .WithVersioningMode("release", VersioningMode.ContinuousDeployment).WithTag("release", "").Build();
        var continuousDeliveryConfiguration = TestConfigurationBuilder.New
            .WithoutVersioningMode()
            .WithVersioningMode("release", VersioningMode.ContinuousDelivery).WithTag("release", "").Build();

        using var fixture = new EmptyRepositoryFixture("main");

        fixture.MakeACommit("one");
        fixture.BranchTo("release/1.0.0");
        fixture.MakeACommit("two");
        fixture.MakeACommit("three");
        fixture.ApplyTag("1.0.0-beta.1");

        fixture.AssertFullSemver("1.0.0-beta", mainlineConfiguration); // expected ???
        fixture.AssertFullSemver("1.0.0-beta.1", continuousDeploymentConfiguration); // expected ???
        fixture.AssertFullSemver("1.0.0-beta.1", continuousDeliveryConfiguration); // expected ???
    }

[enriqueraso]

@HHobeck #3224 contains 2 new unit tests that reproduces the issue.

[HHobeck]

fix included in 6.0.0-beta.1