Added failing tests for #1255, #1844, #2034, #2454, #2693, #2821, #2786 #3445

arturcic · 2023-03-19T09:11:46Z

Closes #1600, #1845, #2059, #2696, #2787, #2830, #2847

HHobeck · 2023-03-19T11:37:04Z

Failed test: Issue #1255, PR #1600 Fixed in #3446

DevelopScenario:
I'm suprised that the author expecting that after a pre-release the semantic version of the next commit increases.

MainScenario:
Here we we have properly a bug in the current version. But this has nothing to do with the orign topic of this issue. I agree with the authors comment that the ordering of semantic versioning is broken... But that's why we have alpha then beta pre-release and not other way around. If we need such a functionality to ensure the order of pre-releases I think it is a new feature which might be worth to implement.

[TestFixture(Description = "Failed test: Issue #1255, PR #1600")]
public class Issue1255Pr1600
{
    [Test(Description = "DevelopScenarios")]
    public void ShouldProvideTheCorrectVersionEvenIfPreReleaseLabelExistsInTheGitTagDevelop()
    {
        var configuration = GitFlowConfigurationBuilder.New.Build();

        using var fixture = new EmptyRepositoryFixture();
        fixture.Repository.MakeACommit("one");
        fixture.ApplyTag("1.0.0-oreo.1");
        fixture.BranchTo("develop");
        fixture.Repository.MakeACommit("two");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.0-alpha.2", configuration);
    }

    [Test(Description = "MainScenarios")]
    public void ShouldProvideTheCorrectVersionEvenIfPreReleaseLabelExistsInTheGitTagMain()
    {
        var configuration = GitFlowConfigurationBuilder.New
            .WithSemanticVersionFormat(SemanticVersionFormat.Loose)
            .WithNextVersion("5.0")
            .WithBranch("main",
                branchBuilder => branchBuilder.WithLabel("beta")
                    .WithIncrement(IncrementStrategy.Patch)
                    .WithVersioningMode(VersioningMode.ContinuousDeployment))
            .Build();

        using EmptyRepositoryFixture fixture = new("main");
        fixture.Repository.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("5.0.0-beta.1", configuration);

        fixture.Repository.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("5.0.0-beta.2", configuration);

        fixture.Repository.MakeATaggedCommit("v5.0.0-rc.1");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("5.0.0-beta.3", configuration);

        fixture.Repository.MakeACommit();

        fixture.AssertFullSemver("5.0.0-beta.4", configuration);
    }
}

HHobeck · 2023-03-19T11:41:19Z

Failed test: Issue #1844, PR #1845

VersionBumpingScenarios:
The same here if the author expecting to bumping the semantic version after a pre-release then it's a new feature and no bug.

[TestFixture(Description = "Failed test: Issue #1844, PR #1845")]
public class Issue1844Pr1845
{
    [Test(Description = "VersionBumpingScenarios")]
    public void AppliedPrereleaseTagAfterBranchTagCausesVersionBump()
    {
        var configuration = GitFlowConfigurationBuilder.New
            .WithBranch(MainBranch,
                branchBuilder => branchBuilder.WithLabel("pre")
                    .WithSourceBranches(ArraySegment<string>.Empty)
                    .WithVersioningMode(VersioningMode.ContinuousDeployment))
            .Build();

        using var fixture = new EmptyRepositoryFixture();
        fixture.Repository.MakeACommit();
        fixture.Repository.MakeATaggedCommit("1.0.0-rc");
        fixture.Repository.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.0-pre.3", configuration);
    }
}

HHobeck · 2023-03-19T12:11:56Z

Failed test: Issue #2034, PR #2059

MainlineDevelopmentMode:
The author defines the develop branch with increment mode Inherit... But if you take a look to the branch configuration of develop it says that develop branch has no source branches:

...
branches:
  develop:
    mode: ContinuousDeployment
    label: alpha
    increment: Minor
    prevent-increment-of-merged-branch-version: false
    track-merge-target: true
    regex: ^dev(elop)?(ment)?$
    source-branches: []
    is-source-branch-for: []
    tracks-release-branches: true
    is-release-branch: false
    is-mainline: false
    pre-release-weight: 0

That means the develop branch has no parents and is orphaned. Thus it yields to an error which I would expect:

[TestFixture(Description = "Failed test: Issue #2034, PR #2059")]
public class Issue2034Pr2059
{
    [Test(Description = "MainlineDevelopmentMode")]
    public void MergingMainBranchToDevelopWithInheritIncrementShouldIncrementDevelopPatch()
    {
        var configuration = GitFlowConfigurationBuilder.New
            .WithAssemblyVersioningScheme(AssemblyVersioningScheme.MajorMinorPatch)
            .WithVersioningMode(VersioningMode.Mainline)
            .WithBranch(MainBranch, branchBuilder => branchBuilder.WithIncrement(IncrementStrategy.Patch))
            .WithBranch("develop", branchBuilder => branchBuilder.WithIncrement(IncrementStrategy.Inherit))
            .Build();

        using var fixture = new EmptyRepositoryFixture();
        fixture.MakeACommit($"initial in {MainBranch}");
        fixture.AssertFullSemver("0.0.1", configuration);
        fixture.MakeACommit($"{MainBranch} change");
        fixture.AssertFullSemver("0.0.2", configuration);
        fixture.BranchTo("develop");

        Action action = () => fixture.AssertFullSemver("0.0.3-alpha.0", configuration);

        // ✅ succeeds as expected
        action.ShouldThrow<GitVersionException>("No base versions determined on the current branch.");
    }
}

Probably it makes more sense to change the test and using instead of develop the feature branch like:

[TestFixture(Description = "Failed test: Issue #2034, PR #2059")]
public class Issue2034Pr2059
{
    [Test(Description = "MainlineDevelopmentMode")]
    public void MergingMainBranchToDevelopWithInheritIncrementShouldIncrementDevelopPatch()
    {
        var configuration = GitFlowConfigurationBuilder.New
            .WithAssemblyVersioningScheme(AssemblyVersioningScheme.MajorMinorPatch)
            .WithVersioningMode(VersioningMode.Mainline)
            .WithBranch(MainBranch, branchBuilder => branchBuilder.WithIncrement(IncrementStrategy.Patch))
            .WithBranch("feature", branchBuilder => branchBuilder
                .WithIncrement(IncrementStrategy.Inherit)
                .WithVersioningMode(null)
            ).Build();

        using var fixture = new EmptyRepositoryFixture();
        fixture.MakeACommit($"initial in {MainBranch}");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("0.0.1", configuration);
        fixture.MakeACommit($"{MainBranch} change");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("0.0.2", configuration);
        fixture.BranchTo("feature/just-a-test");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("0.0.3-just-a-test.0", configuration);

        fixture.MakeACommit("develop change");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("0.0.3-just-a-test.1", configuration);

        fixture.Checkout(MainBranch);
        fixture.MakeACommit($"{MainBranch} hotfix");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("0.0.3", configuration);

        fixture.Checkout("feature/just-a-test");
        fixture.MergeNoFF(MainBranch);

        // ✅ succeeds as expected
        fixture.AssertFullSemver("0.0.4-just-a-test.2", configuration);
    }
}

HHobeck · 2023-03-19T13:11:28Z

Failed test: Issue #2693, PR #2696

HotfixBranchScenarios:
I think the integration test was not written correct. From the test result I'm not sure what the expected behavior is. But what I can say is: This use case makes no sense. Why!? Because to merge the release 1.1.0 to the main branch without tagging the final version with a 1.1.0 tag is problematic. But on the other hand go further and create a bug fix on top of the not released 1.1.0 version. I my opinion this use case is every thing but not following a git flow workflow. It makes more sense to see the hotfix version as 1.0.1 because the version 1.1.0 has not been published. But why would you place a feature release into a hotfix release!?

public class Issue2693Pr2696
{
    [Test(Description = "HotfixBranchScenarios")]
    public void VersionNumberInHotfixBranchShouldBeConsideredWhenPreventIncrementOfMergedBranchVersion()
    {
        var configurationBuilder = GitFlowConfigurationBuilder.New
            .WithAssemblyVersioningScheme(AssemblyVersioningScheme.MajorMinorPatchTag)
            .WithAssemblyFileVersioningFormat("{MajorMinorPatch}.0")
            .WithVersioningMode(VersioningMode.ContinuousDeployment)
            .WithBranch("hotfix", _ => _.WithLabel("ci").WithRegularExpression("^hotfix(es)?[/-]")); // "r^(origin/)?hotfix[/-]"

        const string HotfixBranch = "hotfix/1.1.1";
        const string ReleaseBranch = "release/1.1.0";

        using var fixture = new BaseGitFlowRepositoryFixture("1.0.0");
        Commands.Checkout(fixture.Repository, fixture.Repository.CreateBranch(ReleaseBranch));
        fixture.MakeACommit();
        Commands.Checkout(fixture.Repository, MainBranch);
        fixture.MergeNoFF(ReleaseBranch);
        fixture.BranchTo(HotfixBranch); // fixture.Repository.CreateBranch(HotfixBranch);
        fixture.Repository.MakeACommit();

        // ❔ expected: 1.1.1-ci.1+4 or 1.1.0-ci.1+1
        fixture.AssertFullSemver("1.1.1-ci.1+4",
            configurationBuilder.WithBranch("hotfix", _ => _
                .WithPreventIncrementOfMergedBranchVersion(false)
            ).Build()
        );

        // ❔ expected: 1.1.1-ci.1+4 or 1.1.0-ci.1+1
        fixture.AssertFullSemver("1.1.0-ci.1+1",
            configurationBuilder.WithBranch("hotfix", _ => _
                .WithPreventIncrementOfMergedBranchVersion(true)
            ).Build()
        );
    }
}

The following scenario makes more sense in my opinion and is independent of the property PreventIncrementOfMergedBranchVersion:

[Test(Description = "HotfixBranchScenarios")]
public void VersionNumberInHotfixBranchShouldBeConsideredWhenPreventIncrementOfMergedBranchVersion()
{
    var configurationBuilder = GitFlowConfigurationBuilder.New
        .WithAssemblyVersioningScheme(AssemblyVersioningScheme.MajorMinorPatchTag)
        .WithAssemblyFileVersioningFormat("{MajorMinorPatch}.0")
        .WithVersioningMode(VersioningMode.ContinuousDeployment)
        .WithBranch("main", _ => _.WithTrackMergeMessage(false))
        .WithBranch("hotfix", _ => _.WithLabel("ci").WithRegularExpression("^hotfix(es)?[/-]")); // "r^(origin/)?hotfix[/-]"

    const string HotfixBranch = "hotfix/just-a-hotfix";
    const string ReleaseBranch = "release/1.1.0";

    using var fixture = new BaseGitFlowRepositoryFixture("1.0.0");
    Commands.Checkout(fixture.Repository, fixture.Repository.CreateBranch(ReleaseBranch));
    fixture.MakeACommit();
    Commands.Checkout(fixture.Repository, MainBranch);
    fixture.MergeNoFF(ReleaseBranch);
    fixture.BranchTo(HotfixBranch); // fixture.Repository.CreateBranch(HotfixBranch);
    fixture.Repository.MakeACommit();

    // ✅ succeeds as expected
    fixture.AssertFullSemver("1.0.1-ci.1+4",
        configurationBuilder.WithBranch("hotfix", _ => _
            .WithPreventIncrementOfMergedBranchVersion(false)
        ).Build()
    );

    // ✅ succeeds as expected
    fixture.AssertFullSemver("1.0.1-ci.1+4",
        configurationBuilder.WithBranch("hotfix", _ => _
            .WithPreventIncrementOfMergedBranchVersion(true)
        ).Build()
    );
}

HHobeck · 2023-03-19T14:36:13Z

Failed test: Issue #2821, PR #2830
I need to set the VersioningMode on feature and pull-request to null so the fallback setting on the root configuration applies with VersioningMode.Mainline.

IncrementFeatureByMinor:
This test succeeded like the author might expecting it.

CanCalculatePullRequestChanges:
Why would the author expecting the version 2.1.1-PullRequest3.6? In the configuration the pull-request branch has been explicit set to IncrementStrategy.Minor.

[TestFixture(Description = "Failed test: Issue #2821, PR #2830")]
public class Issue2821Pr2830 : TestBase
{
    private readonly GitVersionConfiguration configuration = GitFlowConfigurationBuilder.New
        .WithVersioningMode(VersioningMode.Mainline)
        .WithBranch("feature", branchBuilder => branchBuilder.WithIncrement(IncrementStrategy.Minor).WithVersioningMode(null))
        .WithBranch("pull-request", branchBuilder => branchBuilder.WithIncrement(IncrementStrategy.Minor).WithVersioningMode(null))
        .WithBranch("support",
            branchBuilder => branchBuilder
                .WithVersioningMode(VersioningMode.ContinuousDeployment)
                .WithLabel("beta")
                .WithIncrement(IncrementStrategy.Patch))
        .Build();

    [Test]
    public void IncrementFeatureByMinor()
    {
        using var fixture = new EmptyRepositoryFixture();
        fixture.MakeATaggedCommit("0.1.0");

        // feature workflow
        fixture.BranchTo("feature/foo", "foo");
        fixture.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("0.2.0-foo.1", this.configuration);
        fixture.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("0.2.0-foo.2", this.configuration);
        fixture.Checkout(MainBranch);
        fixture.MergeNoFF("feature/foo");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("0.2.0", this.configuration);
    }

    [Test]
    public void CanCalculatePullRequestChanges()
    {
        using var fixture = new EmptyRepositoryFixture();
        fixture.Repository.MakeATaggedCommit("1.0.0");
        fixture.Repository.MakeATaggedCommit("1.1.0");
        fixture.Repository.MakeATaggedCommit("2.0.0");

        // feature branch
        Commands.Checkout(fixture.Repository, fixture.Repository.CreateBranch("feature/foo"));
        fixture.Repository.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("2.1.0-foo.1", this.configuration);
        fixture.Repository.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("2.1.0-foo.2", this.configuration);

        // pull request
        fixture.Repository.CreatePullRequestRef("feature/foo", MainBranch, normalise: true);

        // ✅ succeeds as expected
        fixture.AssertFullSemver("2.1.0-PullRequest2.3", this.configuration);
        Commands.Checkout(fixture.Repository, MainBranch);

        fixture.Repository.MergeNoFF("feature/foo", Generate.SignatureNow());

        // ✅ succeeds as expected
        fixture.AssertFullSemver("2.1.0", this.configuration);
        fixture.Repository.MakeATaggedCommit("2.1.0"); // must tag before pull of any hotfix otherwise hotfix stays at this version

        // hotfix branch
        var tag = fixture.Repository.Tags.Single(t => t.FriendlyName == "1.0.0");
        var supportBranch = fixture.Repository.CreateBranch("support/1.0.0", (LibGit2Sharp.Commit)tag.Target);
        Commands.Checkout(fixture.Repository, supportBranch);

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.0", this.configuration);
        fixture.Repository.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.1-beta.1", this.configuration);
        fixture.Repository.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.1-beta.2", this.configuration);
        fixture.Repository.MakeATaggedCommit("1.0.1");
        fixture.Repository.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.2-beta.1", this.configuration);

        // pull request
        fixture.Repository.CreatePullRequestRef("support/1.0.0", MainBranch, 3, normalise: true);
        fixture.Repository.DumpGraph();

        // ✅ succeeds as expected because in the configuration pull-request branch has been set to IncrementStrategy.Minor
        fixture.AssertFullSemver("2.2.0-PullRequest3.7", this.configuration); // 2.1.1-PullRequest3.6
        Commands.Checkout(fixture.Repository, MainBranch);
        fixture.Repository.MergeNoFF("support/1.0.0", Generate.SignatureNow());

        // ✅ succeeds as expected
        fixture.AssertFullSemver("2.1.1", this.configuration);
    }
}

HHobeck · 2023-03-19T14:52:30Z

Failed test: Issue #2786, PR #2787

HotfixBranchesWithTaggedCommitsOnMain:
The hotfix branch inherits from main branch and gets IncrementStrategy.Minor.

HotfixBranchesWithTaggedCommitsOnHotfix:
Why would you tag the hotfix with release 1.2.2? You need to merge it to main first.

[TestFixture(Description = "Failed test: Issue #2786, PR #2787")]
public class Issue2786Pr2787
{
    [Test(Description = "MainlineDevelopmentMode")]
    public void HotfixBranchesWithTaggedCommitsOnMain()
    {
        using var fixture = new EmptyRepositoryFixture();
        var configuration = GitFlowConfigurationBuilder.New
            .WithVersioningMode(VersioningMode.Mainline)
            .WithIncrement(IncrementStrategy.Minor)
            .WithBranch(ConfigurationConstants.MainBranchKey,
                branchBuilder => branchBuilder
                    .WithRegularExpression(ConfigurationConstants.MainBranchRegex)
                    .WithSourceBranches(ConfigurationConstants.DevelopBranchKey, ConfigurationConstants.ReleaseBranchKey)
                    .WithLabel("")
                    .WithPreventIncrementOfMergedBranchVersion(true)
                    .WithIncrement(IncrementStrategy.Minor)
                    .WithIsMainline(true)
                    .WithPreReleaseWeight(55000).WithVersioningMode(null)
            )
            .WithBranch(ConfigurationConstants.HotfixBranchKey, branchBuilder => branchBuilder
                .WithLabel("").WithVersioningMode(null))
            .Build();

        fixture.Repository.MakeACommit("1");
        fixture.MakeATaggedCommit("1.0.0");

        fixture.MakeACommit(); // 1.1.0

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.1.0", configuration);
        fixture.ApplyTag("1.1.0");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.1.0", configuration);

        fixture.BranchTo("hotfix/may");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.2.0", configuration); // hotfix branch inherits from main branch and gets IncrementStrategy.Minor

        // Move main on
        fixture.Checkout(MainBranch);
        fixture.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.2.0", configuration);

        // Continue on hotfix
        fixture.Checkout("hotfix/may");
        fixture.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.3.0", configuration); // hotfix branch inherits from main branch and gets IncrementStrategy.Minor
    }

    [Test(Description = "MainlineDevelopmentMode")]
    public void HotfixBranchesWithTaggedCommitsOnHotfix()
    {
        using var fixture = new EmptyRepositoryFixture();
        var configuration = GitFlowConfigurationBuilder.New
            .WithVersioningMode(VersioningMode.Mainline)
            .WithIncrement(IncrementStrategy.Minor)
            .WithBranch(ConfigurationConstants.MainBranchKey,
                branchBuilder => branchBuilder
                    .WithRegularExpression(ConfigurationConstants.MainBranchRegex)
                    .WithSourceBranches(ConfigurationConstants.DevelopBranchKey, ConfigurationConstants.ReleaseBranchKey)
                    .WithLabel("")
                    .WithPreventIncrementOfMergedBranchVersion(true)
                    .WithIncrement(IncrementStrategy.Minor)
                    .WithIsMainline(true)
                    .WithPreReleaseWeight(55000)
            )
            .WithBranch(ConfigurationConstants.HotfixBranchKey, branchBuilder => branchBuilder.WithLabel(""))
            .Build();

        fixture.Repository.MakeACommit("1");
        fixture.MakeATaggedCommit("1.0.0");

        fixture.MakeACommit(); // 1.1.0

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.1.0", configuration);
        fixture.ApplyTag("1.1.0");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.1.0", configuration);
        fixture.MakeACommit(); // 1.2.0

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.2.0", configuration);

        fixture.BranchTo("hotfix/may");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.2.0+1", configuration); // hotfix branch inherits from main branch and gets IncrementStrategy.Minor

        // Move main on
        fixture.Checkout(MainBranch);
        fixture.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.3.0", configuration);

        // Continue on hotfix
        fixture.Checkout("hotfix/may");
        fixture.MakeACommit();
        fixture.MakeATaggedCommit("1.2.2"); // why would you tag the hotfix with release 1.2.2?
        fixture.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.3.0+1", configuration);
    }
}

HHobeck · 2023-03-19T15:28:12Z

Failed test: Issue #2454, PR #2847

Both tests needsto be adpated because the author misses the fixture::BranchTo step sometimes.

HotfixMergeIncrementsVersionWithModeContinuousDeployment:
SemanticVersionFormat.Loose required for this test. The 1.0.1 hotfix has not been tagged on main. Thus it is not a 1.0.2 hotfix.

HotfixMergeIncrementsVersionWithDefaultConfig:
SemanticVersionFormat.Loose required for this test. The 1.0.1 hotfix has not been tagged on main. Thus it is not a 1.0.2 hotfix.

[TestFixture(Description = "Failed test: Issue #2454, PR #2847")]
public class Issue2454Pr2847
{
    [Test(Description = "HotfixBranchScenarios")]
    public void HotfixMergeIncrementsVersionWithModeContinuousDeployment()
    {
        var configuration = GitFlowConfigurationBuilder.New
            .WithAssemblyVersioningScheme(AssemblyVersioningScheme.MajorMinorPatchTag)
            .WithVersioningMode(VersioningMode.ContinuousDeployment)
            .WithSemanticVersionFormat(SemanticVersionFormat.Loose)
            .Build();

        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");

        // start a release

        const string releaseBranch = "release/1.0";

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

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.0-beta.1", configuration); // SemanticVersionFormat.Loose required for this test

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

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.0", configuration); // no label defined on main branch
        fixture.ApplyTag("1.0");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.0", configuration);

        // start first hotfix

        const string hotfixBranch = "hotfix/something-important";

        fixture.BranchTo(hotfixBranch); // fixture.Repository.CreateBranch(hotfixBranch);
        fixture.Repository.MakeACommit("fix the important issue");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.1-beta.1+1", configuration);
        fixture.Repository.MakeACommit("fix something else");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.1-beta.1+2", configuration);

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

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.1", configuration);

        // start second hotfix

        const string hotfix2Branch = "hotfix/another-important-thing";

        fixture.BranchTo(hotfix2Branch); // fixture.Repository.CreateBranch(hotfix2Branch);
        fixture.Repository.MakeACommit("fix the new issue");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.1-beta.1+4", configuration); // 1.0.1 hotfix has not been tagged on main. Thus it is not a 1.0.2 hotfix here still 1.0.1

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

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.1", configuration); // 1.0.1 has not been tagged previously
    }

    [Test]
    public void HotfixMergeIncrementsVersionWithDefaultConfig()
    {
        var configuration = GitFlowConfigurationBuilder.New
            .WithSemanticVersionFormat(SemanticVersionFormat.Loose)
            .Build();

        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");

        // start a release

        const string releaseBranch = "release/1.0"; // SemanticVersionFormat.Loose required for this test

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

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.0-beta.1+1", configuration);

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

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.0+0", configuration);
        fixture.ApplyTag("1.0");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.0", configuration);

        // start first hotfix

        const string hotfixBranch = "hotfix/something-important";

        fixture.BranchTo(hotfixBranch); // fixture.Repository.CreateBranch(hotfixBranch);
        fixture.Repository.MakeACommit("fix the important issue");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.1-beta.1+1", configuration);
        fixture.Repository.MakeACommit("fix something else");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.1-beta.1+2", configuration);

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

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.1+3", configuration);

        // start second hotfix

        const string hotfix2Branch = "hotfix/another-important-thing";

        fixture.BranchTo(hotfix2Branch); // fixture.Repository.CreateBranch(hotfix2Branch);
        fixture.Repository.MakeACommit("fix the new issue");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.1-beta.1+4", configuration); // 1.0.1 hotfix has not been tagged on main. Thus it is not a 1.0.2 hotfix here still 1.0.1

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

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.1+5", configuration); // 1.0.1 has not been tagged previously
    }
}

Garinoth · 2023-03-23T09:28:37Z

Hello, about Issues #2821 and PR #2830 I was facing The same problem as the author and I think I can explain the situation.

When developing we usually create either a feature or a hottix branch to be merged to main. Then we create a pull request from that branch to be reviewed by peers and pass some quality gates before merging.
I think there was a bit of confusion with that test setting the increment mode to Minor in the pull request, but the thing is if you set it as Inherit it doesn't inherit the strategy from the source branch.

What I'm facing is the following:
Mode: mainline
Main branch increment: Patch
Feature increment: Minor
Hotfix increment: Patch
PR increment: Inherit
PR created from a feature branch: increments Patch
PR created from a hottix branch: increments Patch

I would expect the PR from the feature branch to increment the Minor. This invalidates the use of gitversion with PRs for me.

It seems to be following the increment mode from the Main branch, if I change it it follows it's behavior. I also tried modifying the source-branches to be only feature and hottix for the PRs without success.

Is this the expected behavior?

HHobeck · 2023-03-23T09:38:33Z

Hello, about Issues #2821 and PR #2830 I was facing The same problem as the author and I think I can explain the situation.

When developing we usually create either a feature or a hottix branch to be merged to main. Then we create a pull request from that branch to be reviewed by peers and pass some quality gates before merging. I think there was a bit of confusion with that test setting the increment mode to Minor in the pull request, but the thing is if you set it as Inherit it doesn't inherit the strategy from the source branch.

What I'm facing is the following: Mode: mainline Main branch increment: Patch Feature increment: Minor Hotfix increment: Patch PR increment: Inherit PR created from a feature branch: increments Patch PR created from a hottix branch: increments Patch

I would expect the PR from the feature branch to increment the Minor. This invalidates the use of gitversion with PRs for me.

It seems to be following the increment mode from the Main branch, if I change it it follows it's behavior. I also tried modifying the source-branches to be only feature and hottix for the PRs without success.

Is this the expected behavior?

Have you seen this? #2821 (comment) Please provide a integration test for your scenario if you still think it is not solved in version 6.x. To answer your question: If the branch is set to the IncrementMode Inherit it should work with different modes yes.

Bumps [actions/stale](https://github.com/actions/stale) from 7 to 8. - [Release notes](https://github.com/actions/stale/releases) - [Changelog](https://github.com/actions/stale/blob/main/CHANGELOG.md) - [Commits](actions/stale@v7...v8) --- updated-dependencies: - dependency-name: actions/stale dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>

Added GitVersion.Abstractions module

Revert "Added GitVersion.Abstractions module"

…utput)

Use IGitVersionConfiguration instead of GitVersionConfiguration (where possible)

Garinoth · 2023-03-31T16:32:39Z

Hello, about Issues #2821 and PR #2830 I was facing The same problem as the author and I think I can explain the situation.
When developing we usually create either a feature or a hottix branch to be merged to main. Then we create a pull request from that branch to be reviewed by peers and pass some quality gates before merging. I think there was a bit of confusion with that test setting the increment mode to Minor in the pull request, but the thing is if you set it as Inherit it doesn't inherit the strategy from the source branch.
What I'm facing is the following: Mode: mainline Main branch increment: Patch Feature increment: Minor Hotfix increment: Patch PR increment: Inherit PR created from a feature branch: increments Patch PR created from a hottix branch: increments Patch
I would expect the PR from the feature branch to increment the Minor. This invalidates the use of gitversion with PRs for me.
It seems to be following the increment mode from the Main branch, if I change it it follows it's behavior. I also tried modifying the source-branches to be only feature and hottix for the PRs without success.
Is this the expected behavior?

Have you seen this? #2821 (comment) Please provide a integration test for your scenario if you still think it is not solved in version 6.x. To answer your question: If the branch is set to the IncrementMode Inherit it should work with different modes yes.

Sorry for my late response, my week has been hectic. I was indeed using 5.12 as it was the stable release, but you are right the problem is 100% fixed in version 6.0.0-beta.1. Thanks for the response!

#2665 - fix issues templates

Bumps [Cake.Http](https://github.com/cake-contrib/Cake.Http) from 2.0.0 to 3.0.2. - [Release notes](https://github.com/cake-contrib/Cake.Http/releases) - [Changelog](https://github.com/cake-contrib/Cake.Http/blob/develop/GitReleaseManager.yaml) - [Commits](cake-contrib/Cake.Http@2.0.0...3.0.2) --- updated-dependencies: - dependency-name: Cake.Http dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>

…-contains-the-word-refs Fix Bug: Branch names cannot contain the word 'refs' #3103

…tp-3.0.2 (ci deps): Bump Cake.Http from 2.0.0 to 3.0.2 in /build

This was referenced Mar 19, 2023

Pre-release label in git tag #1600

Closed

Failing Unit Test for Issue #1844 #1845

Closed

#2034 StackOverflow when using increment: Inherit: new unit test #2059

Closed

Version number in hotfix branch should not be ignored #2696

Closed

arturcic added breaking change failing test case and removed breaking change labels Mar 19, 2023

arturcic force-pushed the bug/failing-tests branch from cd8e844 to 8366229 Compare March 19, 2023 09:31

arturcic changed the title ~~Added failing tests for #1255, #1844, #2034, #2693~~ Added failing tests for #1255, #1844, #2034, #2693, #2821 Mar 19, 2023

arturcic mentioned this pull request Mar 19, 2023

Test Scenario for troubleshooting question/issue #2821 #2830

Closed

5 tasks

arturcic force-pushed the bug/failing-tests branch from 8366229 to 3deab7a Compare March 19, 2023 10:09

arturcic changed the title ~~Added failing tests for #1255, #1844, #2034, #2693, #2821~~ Added failing tests for #1255, #1844, #2034, #2693, #2821, #2786 Mar 19, 2023

arturcic mentioned this pull request Mar 19, 2023

Tests for issue 2786 #2787

Closed

arturcic force-pushed the bug/failing-tests branch from 3deab7a to 2555f66 Compare March 19, 2023 10:23

arturcic changed the title ~~Added failing tests for #1255, #1844, #2034, #2693, #2821, #2786~~ Added failing tests for #1255, #1844, #2034, #2454, #2693, #2821, #2786 Mar 19, 2023

arturcic mentioned this pull request Mar 19, 2023

Add unit test to investigate and hopefully verify #2454 #2847

Closed

5 tasks

arturcic force-pushed the bug/failing-tests branch from 2555f66 to 3066a02 Compare March 19, 2023 10:46

arturcic force-pushed the bug/failing-tests branch from 3066a02 to 1ea3216 Compare March 19, 2023 14:24

HHobeck mentioned this pull request Mar 21, 2023

Fix wrong version generation for ContinuesDeployment actual: 5.0.0-beta.1+3 expected 5.0.0-beta.3 #3446

Merged

5 tasks

arturcic force-pushed the bug/failing-tests branch from 1ea3216 to f0d9301 Compare March 22, 2023 08:10

arturcic added 20 commits March 26, 2023 16:39

fixed approved files

23e2390

convert GitVersionVariables to record

065a34f

removed ReflectionIgnore attribute from GitVersionVariable

516f2e7

order properties

83dbf0e

added GitVersion.Abstractions

5edab63

moved Agents ang Git interfaces

2adb521

moved some Configuration interfaces

8d8496c

use configuration builder in init module

a2299d0

use BranchConfigurationBuilder

6401cd4

move more interfaces to Abstractions

683ca38

decoupled modules from core and use abstractions instead

06d76e5

fix api analyzer errors

ea49bfa

Merge pull request #3451 from arturcic/feature/abstractions

7feae1d

Added GitVersion.Abstractions module

Revert "Added GitVersion.Abstractions module"

488a150

Merge pull request #3452 from GitTools/revert-3451-feature/abstractions

d187a01

Revert "Added GitVersion.Abstractions module"

made classes that should not be exposed, internal (App, MsBuild and O…

059ee5f

…utput)

use IGitVersionConfiguration instead of GitVersionConfiguration

8b6f878

use IBranchConfiguration instead of BranchConfiguration

458090a

Merge pull request #3454 from arturcic/feature/configuration

71e0e98

Use IGitVersionConfiguration instead of GitVersionConfiguration (where possible)

made classes that should not be exposed, internal (Core)

1cb9bb8

arturcic and others added 7 commits April 4, 2023 12:21

#2665 - fix issues templates

dfa86cb

Merge pull request #3457 from arturcic/bug/2665

f1ced75

#2665 - fix issues templates

Fix Bug: Branch names cannot contain the word 'refs' #3103

0acceaf

Merge pull request #3459 from HHobeck/feature/3103_branch-name-cannot…

1ef74f4

…-contains-the-word-refs Fix Bug: Branch names cannot contain the word 'refs' #3103

Merge pull request #3458 from GitTools/dependabot/nuget/build/Cake.Ht…

4e6051a

…tp-3.0.2 (ci deps): Bump Cake.Http from 2.0.0 to 3.0.2 in /build

Added failing tests for #1255, #1844, #2034, #2454, #2693, #2821, #2786

eb35aff

arturcic closed this Apr 5, 2023

arturcic deleted the bug/failing-tests branch April 6, 2023 12:00

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added failing tests for #1255, #1844, #2034, #2454, #2693, #2821, #2786 #3445

Added failing tests for #1255, #1844, #2034, #2454, #2693, #2821, #2786 #3445

arturcic commented Mar 19, 2023 •

edited

Loading

HHobeck commented Mar 19, 2023 •

edited

Loading

HHobeck commented Mar 19, 2023

HHobeck commented Mar 19, 2023 •

edited

Loading

HHobeck commented Mar 19, 2023 •

edited

Loading

HHobeck commented Mar 19, 2023

HHobeck commented Mar 19, 2023 •

edited

Loading

HHobeck commented Mar 19, 2023

Garinoth commented Mar 23, 2023

HHobeck commented Mar 23, 2023

Garinoth commented Mar 31, 2023

Added failing tests for #1255, #1844, #2034, #2454, #2693, #2821, #2786 #3445

Added failing tests for #1255, #1844, #2034, #2454, #2693, #2821, #2786 #3445

Conversation

arturcic commented Mar 19, 2023 • edited Loading

HHobeck commented Mar 19, 2023 • edited Loading

HHobeck commented Mar 19, 2023

HHobeck commented Mar 19, 2023 • edited Loading

HHobeck commented Mar 19, 2023 • edited Loading

HHobeck commented Mar 19, 2023

HHobeck commented Mar 19, 2023 • edited Loading

HHobeck commented Mar 19, 2023

Garinoth commented Mar 23, 2023

HHobeck commented Mar 23, 2023

Garinoth commented Mar 31, 2023

arturcic commented Mar 19, 2023 •

edited

Loading

HHobeck commented Mar 19, 2023 •

edited

Loading

HHobeck commented Mar 19, 2023 •

edited

Loading

HHobeck commented Mar 19, 2023 •

edited

Loading

HHobeck commented Mar 19, 2023 •

edited

Loading