When incrementing version using commit message, we only consider tags with a valid version

[adaskos-signal]

Description

Changed method FindCommitMessageIncrement in IncrementStrategyFinder to consider SHA from tags that have semantic versioning, by reusing GetTaggedSemanticVersions of IRepositoryStore.

The change requires removing the tagsShaCache since the discovery must account for the currently used configuration and its prefix.

Related Issue

See issue #3757

Motivation and Context

The current behavior won't allow any other tagging (by the CI or users) to co-exist with version bumping commits.

The problem appears when any of the commits attempting to bump the version come before a tag that is not version related.

The current implementation will ignore those commits, assuming it will find a version forcing tag, when in reality there's no version defined in it.

How Has This Been Tested?

Added a new theory in VersionBumpingScenarios.cs with 5 test cases covering prefixed versions too.

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[HHobeck]

So far your PR looks good. The following use cases coming to my mind:

1. When tagging a commit with a pre-release version 1.9.0-1 on main branch with no label (null) the result will be 1.9.0-2 on next commit
2. When tagging a commit with a pre-release version 1.9.0-1 on main branch with empty label the result will be 1.9.0-2 on next commit
3. When tagging a commit with a pre-release version 1.9.0-alpha.1 on main branch with no label (null) the result will be 1.9.0-alpha.2 on next commit
4. When tagging a commit with a pre-release version 1.9.0-alpha.1 on main branch with empty label the result will be 2.0.0-2 on next commit
5. When tagging a commit with a pre-release version 2.1.0-alpha.1 on main branch with empty label the result will be 2.1.0-2 on next commit

[adaskos-signal]

Is what you describe the expected behavior?

In main branch as it stands now it works differently:
when tagging a commit with a pre-release version 1.9.0-alpha.1 on main branch with no label (null) the result is 1.9.0-1 and the next commit result is 1.9.0-2.
The main branch uses the version, but doesn't copy the label from the tag. It uses the one configured for the branch (empty)

[HHobeck]

Actually the desired behaviour is to use the label as pre-release name if not set to null.

Can you try this?

var configuration = GitFlowConfigurationBuilder.New.WithLabel(null).WithBranch("main", _ => _.WithLabel(null)).Build()

Please see the following unit tests:

https://github.com/GitTools/GitVersion/blob/8e1c745c5a8fbc27b75ab71cb7e71052e2f05855/src/GitVersion.Core.Tests/IntegrationTests/OtherScenarios.cs#L258C17-L258C106

[HHobeck]

So far your PR looks good. The following use cases coming to my mind:

1. When tagging a commit with a pre-release version 1.9.0-1 on main branch with no label (null) the result will be 1.9.0-2 on next commit
2. When tagging a commit with a pre-release version 1.9.0-1 on main branch with empty label the result will be 1.9.0-2 on next commit
3. When tagging a commit with a pre-release version 1.9.0-alpha.1 on main branch with no label (null) the result will be 1.9.0-alpha.2 on next commit
4. When tagging a commit with a pre-release version 1.9.0-alpha.1 on main branch with empty label the result will be 2.0.0-2 on next commit
5. When tagging a commit with a pre-release version 2.1.0-alpha.1 on main branch with empty label the result will be 2.1.0-2 on next commit

@adaskos-signal: If you take this integration tests you will see that your PR needs lets say a little bit fine tuning ;):

[TestCase("", null, "1.9.0-1", "2.0.0-1+1", ExpectedResult = "1.9.0-1")]
[TestCase("", "", "1.9.0-1", "2.0.0-1+1", ExpectedResult = "1.9.0-1")]
[TestCase("", "foo", "1.9.0-1", "2.0.0-foo.1+1", ExpectedResult = "2.0.0-foo.1+1")]
[TestCase("", "bar", "1.9.0-1", "2.0.0-bar.1+1", ExpectedResult = "2.0.0-bar.1+1")]
[TestCase("prefix", null, "1.9.0-1", "2.0.0-1+1", ExpectedResult = "2.0.0-1+1")]
[TestCase("prefix", "", "1.9.0-1", "2.0.0-1+1", ExpectedResult = "2.0.0-1+1")]
[TestCase("prefix", "foo", "1.9.0-1", "2.0.0-foo.1+1", ExpectedResult = "2.0.0-foo.1+1")]
[TestCase("prefix", "bar", "1.9.0-1", "2.0.0-bar.1+1", ExpectedResult = "2.0.0-bar.1+1")]

[TestCase("", null, "2.1.0-1", "2.0.0-1+1", ExpectedResult = "2.1.0-1")]
[TestCase("", "", "2.1.0-1", "2.0.0-1+1", ExpectedResult = "2.1.0-1")]
[TestCase("", "foo", "2.1.0-1", "2.0.0-foo.1+1", ExpectedResult = "2.1.0-foo.1+1")]
[TestCase("", "bar", "2.1.0-1", "2.0.0-bar.1+1", ExpectedResult = "2.1.0-bar.1+1")]
[TestCase("prefix", null, "2.1.0-1", "2.0.0-1+1", ExpectedResult = "2.0.0-1+1")]
[TestCase("prefix", "", "2.1.0-1", "2.0.0-1+1", ExpectedResult = "2.0.0-1+1")]
[TestCase("prefix", "foo", "2.1.0-1", "2.0.0-foo.1+1", ExpectedResult = "2.0.0-foo.1+1")]
[TestCase("prefix", "bar", "2.1.0-1", "2.0.0-bar.1+1", ExpectedResult = "2.0.0-bar.1+1")]
public string WhenTaggingACommitAsPreRelease(string tagPrefix, string? label, string tag, string expectedVersion)
{
    var configuration = GitFlowConfigurationBuilder.New.WithLabel(null).WithTagPrefix(tagPrefix)
        .WithBranch("main", _ => _.WithLabel(label).WithVersioningMode(VersioningMode.ContinuousDelivery))
        .Build();

    using EmptyRepositoryFixture fixture = new("main");

    fixture.MakeATaggedCommit($"{tagPrefix}1.0.0");
    fixture.MakeACommit("+semver:major");
    fixture.AssertFullSemver(expectedVersion, configuration);
    fixture.ApplyTag(tag);

    return fixture!.GetVersion(configuration).FullSemVer;
}