[Bug] GitVersion mainline always returns latest version based on master branch history, even if building for an older commit

[esimkowitz]

Describe the bug
My team's build agents sometimes slow down, meaning that new commits are checked into our main branch before old ones have been built. I'm noticing that when GitVersion runs (in separate pipeline runs) for these two backed-up commits, it is applying the same version to both commits.

Expected Behavior

I expect that when GitVersion mainline runs for a specific commit hash, it will generate the version for that hash and not for the latest commit, as it appears to be doing.

Actual Behavior

GitVersion mainline generates the commit for the latest commit hash, even if the commit that is checked out in the build agent (or locally) is older than the latest.

Possible Fix

MainlineVersionCalculator.IncrementForEachCommit should stop at the current reference hash, rather than run for all direct commits on the target master branch.

Steps to Reproduce

Run GitVersion with mainline configuration for the head of the master branch, record the version returned. Then, switch your commit to the next-oldest commit in the branch. You should see that the same version is produced.

Context

In our case, we error out a build if the same version is generated for two commits as it will cause conflicts in our container image tags. While this does not necessarily cause later builds to fail, since we tag the commit after a successful build providing a new base for versioning, it does cause our build pipelines to be flaky when handling commits in rapid succession.

Your Environment

Azure DevOps YAML pipelines and .NET .

• Version Used: 5.5.1, also reproduced in 5.10.3
• Operating System and version (Windows 10, Ubuntu 18.04): Ubuntu 22.04 and Windows 11
• Link to your project: Not publicly available
• Link to your CI build (if appropriate): Not publicly available

Here's the output from gitversion showing it using the latest commit, instead of the current commit to calculate the version:

INFO [09/23/22 9:53:15:59] Found multiple base versions which will produce the same SemVer (1.1.73), taking oldest source for commit counting (Git tag '1.1.72')
    INFO [09/23/22 9:53:15:59] Base version used: Git tag '1.1.72': 1.1.72 with commit count source ae487caac07dafa44d5396bdeda9f1e0fd84d1c1
  INFO [09/23/22 9:53:15:59] End: Calculating base versions (Took: 767.63ms)   
  INFO [09/23/22 9:53:15:60] Begin: Using mainline development mode to calculate current version
    INFO [09/23/22 9:53:15:69] Found possible mainline branches: xxx/test-main
    INFO [09/23/22 9:53:15:73] Mainline for current branch is xxx/test-main
    INFO [09/23/22 9:53:15:74] Direct commit on master 5ac034636007d74195e9f625282f8e1d29b99895 incremented base versions Patch, now 1.1.73
    INFO [09/23/22 9:53:15:74] Direct commit on master 4ecd4ec06985ff50af0f878d7700b1a9af408f1d incremented base versions Patch, now 1.1.74
    INFO [09/23/22 9:53:15:74] Direct commit on master 97d6e4faee6586b2518ae3f95b41407692b76f2f incremented base versions Patch, now 1.1.75
    INFO [09/23/22 9:53:15:74] 2 commits found between ae487caac07dafa44d5396bdeda9f1e0fd84d1c1 and 4ecd4ec06985ff50af0f878d7700b1a9af408f1d

[esimkowitz]

Here's my proposed change: esimkowitz@6ef5caf

I tried to add a test for this behavior in NextVersionCalculatorTests that would create a commit, record the hash and version, create another commit, record the version, then checkout the first commit in detached mode and ensure that the first version is shown and not the second version. This is the way that I was able to reproduce this bug against the official release. Unfortunately, I kept getting an error from GitPreparer.EnsureHeadIsAttachedToBranch saying that I could not do this. Not sure why I can run against a detached HEAD with the release version but not when running the tests?

[esimkowitz]

I've also reproduced this bug in the latest release 5.10.3

[HHobeck]

Have you tried to use GitVersion with the parameter gitversion /c {commit-id}? Please see gitversion /help for more information.

# Remote repository args
...
    /c              The commit id to check. If not specified, the latest
                    available commit on the specified branch will be used.

Also you can use the yaml configuration to ignore commits like:

ignore:
    sha: [b6c0c9fda88830ebcd563e500a5a7da5a1658e98]
    commits-before: 2015-10-23T12:23:15

I'm not sure what you did exactly but I think detached head is not supported with gitversion.

[esimkowitz]

using the -c flag still produces the incorrect version. I haven't done anything special to the tool to get it to work in detached mode, I simply run dotnet gitversion...

here's my GitVersion.yml file if anyone sees something I'm doing wrong here

mode: Mainline
assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatch
branches:
  master:
    regex: ^(origin\/)?main$
    is-mainline: true
ignore:
  sha: []
merge-message-formats: {}

[esimkowitz]

Also worth noting in here that we are using the -nonormalize flag because our build admins require that we host our pipelines and code in separate repositories. We have an extra checkout step in our pipelines to check out the code repository onto the agent and if we don't have the -nonormalize field, it will version the build with the pipeline repository history, instead of the code repository history.

[esimkowitz]

@asbjornu I see now that this is listed as a known issue for mainline, has anyone else attempted to correct this issue?

[HHobeck]

May I ask you to explain your scenario based on an integration test? If you take the following example what is your expectation?

[Test]
public void Just_A_Test()
{
    var configuration = GitHubFlowConfigurationBuilder.New
        .WithBranch("main", _ => _
            .WithIncrement(IncrementStrategy.Patch).WithVersioningMode(VersioningMode.Mainline)
        ).WithBranch("feature", _ => _
            .WithVersioningMode(VersioningMode.Mainline)
        ).Build();

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

    fixture.MakeATaggedCommit("1.0.0");

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

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

    fixture.Checkout("main");
    fixture.MakeACommit();
    fixture.Checkout("feature/foo");

    // ✅ succeeds as expected
    fixture.AssertFullSemver("1.0.1-foo.1", configuration);
}

Does it reflect you use case? I'm asking because I'm not sure if it is really a bug.

[github-actions]

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.

[HHobeck]

May I ask you to explain your scenario based on an integration test? If you take the following example what is your expectation?

[Test]
public void Just_A_Test()
{
    var configuration = GitHubFlowConfigurationBuilder.New
        .WithBranch("main", _ => _
            .WithIncrement(IncrementStrategy.Patch).WithVersioningMode(VersioningMode.Mainline)
        ).WithBranch("feature", _ => _
            .WithVersioningMode(VersioningMode.Mainline)
        ).Build();

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

    fixture.MakeATaggedCommit("1.0.0");

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

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

    fixture.Checkout("main");
    fixture.MakeACommit();
    fixture.Checkout("feature/foo");

    // ✅ succeeds as expected
    fixture.AssertFullSemver("1.0.1-foo.1", configuration);
}

Does it reflect you use case? I'm asking because I'm not sure if it is really a bug.

@esimkowitz Could you please answer?