Mainline in 6.0.0 with default configuration values throws

[fvaillancourt]

Prerequisites

• I have written a descriptive issue title
• I have searched issues to ensure it has not already been reported

GitVersion package

GitVersion.Tool, GitVersion.MsBuild

GitVersion version

6.0.0

Operating system

Linux

What are you seeing?

Using mainline strategy, when building on github in a PR, it says:

An orphaned branch 'origin/feature/name-of-branch' has been detected and will be skipped=True.

And a bit further I get:

System.InvalidOperationException: Operation is not valid due to the current state of the object.
    at GitVersion.VersionCalculation.MainlineVersionStrategy.GetCommitsWasBranchedFrom(IBranch branch, IBranch[] excludedBranches) in /_/src/GitVersion.Core/VersionCalculation/VersionSearchStrategies/MainlineVersionStrategy.cs:line 299

I am using the default configuration except for adding mainline strategy.
The issue seems to be that the parent of the pr branch created by github, is my branch which is being built, and it match to the pull-request branch configuration. That branch configuration has an inherit increment, and when mainline is trying to go up from my pr branch to find a main, it hits that pull-request level, which in default configuration, does NOT have the is-main-branch value set and it makes it throw.

What is expected?

I expect default configuration not to throw.
Adding the missing is-main-branch makes it work, so it would be nice if the default configuration had it. Here is the complete configuration that made it work. (All other branches configurations have that attribute ... probably just forgot it on pull request?)

strategies:
- Fallback
- ConfiguredNextVersion
- MergeMessage
- TaggedCommit
- TrackReleaseBranches
- VersionInBranchName
- Mainline
branches:
  pull-request:
    is-main-branch: false

Steps to Reproduce

Build a pull request on GitHub with this configuration:

strategies:
- Fallback
- ConfiguredNextVersion
- MergeMessage
- TaggedCommit
- TrackReleaseBranches
- VersionInBranchName
- Mainline

RepositoryFixture Test

No response

Output log or link to your CI build (if appropriate).

No response

[HHobeck]

That branch configuration has an inherit increment, and when mainline is trying to go up from my pr branch to find a main, it hits that pull-request level, which in default configuration, does NOT have the is-main-branch value set and it makes it throw.

That is exactly the magic of using branch configuration with the inheritance option. GitVersion is taking (inherits) the value from the parent branch. From your exception output I can see that gitversion complains about, that your feature branch is orphaned. Means you have no parent branch like main which is mandatory.

Please create an integration test or give some examples by e.g. defining git commands to reproduce your scenario.

Thank you!

[fvaillancourt]

Hi, here is a test that can reproduce the issue. Took me a while to make it as I did not exactly know how to get in the situation.

        [Test]
        public void IssueTest()
        {
            using var fixture = new EmptyRepositoryFixture();

            fixture.MakeACommit();
            fixture.BranchTo("offending-branch");
            fixture.MakeACommit();
            fixture.Checkout("main");
            fixture.MergeTo("offending-branch");
            fixture.Repository.CreatePullRequestRef("offending-branch", "main", prNumber: 4, normalise: true);

            IGitVersionConfiguration mainline = GitHubFlowConfigurationBuilder.New
                .WithVersionStrategy(VersionStrategies.Mainline)
                //This will fix it .WithBranch("pull-request", b => b.WithIsMainBranch(false))
                .Build();

            Console.WriteLine(fixture.GetVersion(mainline).FullSemVer);
        }

This crash in the same manner as described in the bug. Here are git commands to create the repo

git init
git add GitVersion.yaml
git commit -m "Initial commit"
git checkout -b offending-branch
copy GitVersion.yaml some.file
git add some.file
git commit -m "Some file"
git checkout main
copy GitVersion.yaml other.file
git add other.file
git commit -m "Other file"
git checkout offending-branch
git merge main
git checkout main
git merge --no-ff offending-branch
git branch pull/4/merge

It assumes that you have this GitVersion.yml file in the directory already

strategies:
- Fallback
- ConfiguredNextVersion
- MergeMessage
- TaggedCommit
- TrackReleaseBranches
- VersionInBranchName
- Mainline

So now that I understand the cause better, I guess you will say we should not have merged main into a branch ... It was before we started using gitversion (and mainline), and not the brightest idea imho.
And adding the missing is main branch false to the pull-request does fix it. Just wanted to suggest to maybe add that config to the default value so it does not crash for others who merged main into a branch and back.

[HHobeck]

Actually this configuration makes no sense in my opinion:

strategies:
- Fallback
- ConfiguredNextVersion
- MergeMessage
- TaggedCommit
- TrackReleaseBranches
- VersionInBranchName
- Mainline

The mainline version strategy can be seen as a strategy which already includes most of the other strategies. But with the goal not to be dependent on tags. Please try the following configuration instead:

strategies:
- ConfiguredNextVersion
- Mainline

[fvaillancourt]

Thanks for explaining what the configuration should be. However even with that new configuration it still does crash. (Updated previous comment to add missing a in yaml)

[HHobeck]

Thank you very much providing the integration test. Indeed merging back from main to the development branch can be problematic:

• [ISSUE]: NotImplementedException in TrunkBased-Workflow #4056

Anyway I think your use case is different. If you use the following workflow it works like expected:

  [Test]
  public void IssueTest()
  {
      using var fixture = new EmptyRepositoryFixture();

      fixture.MakeACommit();
      fixture.BranchTo("offending-branch");
      fixture.MakeACommit();
      fixture.Checkout("main");
      fixture.MergeTo("offending-branch");
      fixture.Repository.CreatePullRequestRef("offending-branch", "main", prNumber: 4, normalise: true);

      IGitVersionConfiguration trunkBased = TrunkBasedConfigurationBuilder.New.Build();

      // ✅ succeeds as expected
      fixture.AssertFullSemver("0.0.2-PullRequest4.2", trunkBased);
  }

The problem is that the Mainline version strategy does not work well with the Inherit increment in your scenario. To be precise the algorithm has problems to inherit from the branch if you have a cascaded parent branch structure (pull-request -> unknown -> main). This is not supported.

That is exactly the reason why in the configuration of the TrunkBased workflow, all increments have been defined with a dedicated value:

• main
• feature
• hotfix
• unknown

Thus, if you want to use the Mainline version strategy I would recommend you to use either the TrunkBased/preview1 workflow or define the increment property with a value not equal to Inherit.

If you like you can change the exception to have a meaningfull message as well.