Pull Request Version Calculation Based on source branch

[anderson-dev]

I'm using mainline versioning mode where my feature branches increment by minor. In my scenario below, pull request version reflects the current version of master rather than the feature branch that the pull request is based on:

master
0.1.0
master -> feature/foo
commit
0.2.0-foo.1
feature/foo -> pull/8/merge
0.1.1-PullRequest00008.1
pull/8/merge -> master
0.2.0 (as expected)

I've tried changing the increment mode for pullrequests in my gitversion.yml branch config but it just changes the increment based on master. How would I tell it to simply take its version from the calculated version of the feature branch for which the pull request was created?

[asbjornu]

What happens if you set track-merge-target: true for pull-request?

[anderson-dev]

Find an integration test below, XenoLibPackages#CanCalculatePullRequestChanges, that reproduces my issue. I tried 'track-merge-target: true' with no dice. The only other configuration that seems like it may be related is specifying the source branches?

using GitTools.Testing;
using GitVersion.Core.Tests.Helpers;
using GitVersion.Model.Configuration;
using GitVersion.VersionCalculation;
using LibGit2Sharp;
using NUnit.Framework;
using System.Collections.Generic;

namespace GitVersion.Core.Tests.IntegrationTests
{
    public class XenoLibPackages : TestBase
    {
        private readonly Config config = new Config
        {
            VersioningMode = VersioningMode.Mainline,
            Branches = new Dictionary<string, BranchConfig>
            {
                {
                    "feature", new BranchConfig
                    {
                        Increment = IncrementStrategy.Minor
                    }
                },
                {
                    "pull-request", new BranchConfig
                    {
                        Regex = @"^(pull|pull\-requests|pr)[/-]",
                        Increment = IncrementStrategy.None,
                        TrackMergeTarget = true
                    }
                }
            }
        };

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

            // feature workflow
            fixture.BranchTo("feature/foo", "foo");
            fixture.MakeACommit();
            fixture.AssertFullSemver("0.2.0-foo.1", config);
            fixture.MakeACommit();
            fixture.AssertFullSemver("0.2.0-foo.2", config);
            fixture.Checkout(MainBranch);
            fixture.MergeNoFF("feature/foo");
            fixture.AssertFullSemver("0.2.0", config);
        }

        [Test]
        public void CanCalculatePullRequestChanges()
        {
            using var fixture = new EmptyRepositoryFixture();
            fixture.Repository.MakeATaggedCommit("0.1.0");
            Commands.Checkout(fixture.Repository, fixture.Repository.CreateBranch("feature/foo"));
            fixture.Repository.MakeACommit();
            fixture.AssertFullSemver("0.2.0-foo.1", config);

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

            fixture.Repository.DumpGraph();
            fixture.AssertFullSemver("0.2.0-PullRequest0002.2");
        }
    }
}

[anderson-dev]

source branches didn't seem to have an effect either

[HHobeck]

master
0.1.0
master -> feature/foo
commit
0.2.0-foo.1
feature/foo -> pull/8/merge
0.1.1-PullRequest00008.1
pull/8/merge -> master
0.2.0 (as expected)

I agree with you. In my opinion this is an unsupported feature:

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

    using EmptyRepositoryFixture fixture = new("main");

    fixture.MakeACommit();

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

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

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

    fixture.BranchTo("pull/8/merge");

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

    fixture.Checkout("main");
    fixture.MergeNoFF("pull/8/merge");
    fixture.Repository.Branches.Remove("pull/8/merge");

    // ❌ expected: 0.1.0
    fixture.AssertFullSemver("0.0.2", configuration);
}

[vbomfim]

Hi @HHobeck / @anderson-dev ,

Do you know if this scenario is supported now?
I believe I have the same issue.
GitVersion produces the right version running on top of the feature branch bumping the minor version.
But in the PR pipeline to merge the feature to the main branch, GitVersion produces the wrong version bumping the patch version.

It knows that it is a merge coming from a feature branch:
HEAD is merge commit, this is likely a pull request using feature/...

But it takes the last release version, and commits with the same base, and bumps the patch version.

Thanks in advance,
Vinicius Bomfim

[HHobeck]

It knows that it is a merge coming from a feature branch:
HEAD is merge commit, this is likely a pull request using feature/...

Hi Vinicius.

I'm actually not sure if this scenario can be realized at all. If you take a look on the branch history then git version cannot determine where the merge is coming from:

Thus if you have such a process with PR you need to think of either changing your workflow or changing the release branch strategy:

• you can ship the artefacts from a previous build e.g. PR build or develop build
• you can use bump messages in commits or in the merge commit message
• you can create a tag on main branch

Please see following links:

• Automatic Semantic Versioning using GitVersion, Azure DevOps Pipeline and Merge (no FF) Pullrequest Merge type.
• Customizable templates for the default merge commit message
• Change default title for pull request commits to not include PR id
• Mainline Not Incrementing SemVer #2955