MergeMessage Strategy using Azure DevOps & Squash Merges

[DSpirit]

Hello,

we are using GitVersion 6.0.0-beta.7 in our Azure DevOps environment and have configured it as follows:

workflow: GitHubFlow/v1
tag-prefix: '[vV]?'
update-build-number: true
strategies:
- MergeMessage
- TaggedCommit
- TrackReleaseBranches
- VersionInBranchName
branches:
  main:
    regex: ^master$|^main$
    label: 'ci'
    prevent-increment:
      of-merged-branch: true
  release:    
    regex: ^release(s)?[/-](?<BranchName>.+)
    label: 'rc'
    is-release-branch: true
    prevent-increment:
      of-merged-branch: true
      when-current-commit-tagged: false
  unknown:
    increment: Inherit
    regex: (?<BranchName>.+)
ignore:
  sha: []

Let's assume we create release branches following this format: release/2.0.0 and want to merge it back to main to increment the version as specified. This works only as long as we don't use Squash Commits, as the MergeMessage strategy needs at least 2 parent commits before getting active in the GitVersion task - this isn't given when using the Azure DevOps Squash Merge Policy.

If we choose Basic Merge, the version gets incremented as expected.

Is there any reason for the MergeMessage to expect 2 parent commits and / or is there any workaround to increment the main version as defined in the release branch despite of using Squash merges?

[HHobeck]

Hi there. Actually, this is a good question. Maybe at the time gitversion was created, squash merges were not so common. Could you give me an example how the history of git will look like after you have merged it?

[DSpirit]

Thanks, here's the release branch (2 commits on readme):

And here after merge (Version generated is 12.x.x instead of 14.0.0, as shown in the logs below):

The MergeMessage strategy just finds an old release, that I've merged using the Basic Merge strategy:

  INFO [03/17/24 13:41:11:86] -< Begin: [Using 'MergeMessageVersionStrategy' strategy] >-
    INFO [03/17/24 13:41:11:92] Found commit ['5372953' - Merged PR 323216 from release/12.4.0 into main Merge] matching merge message format: AzureDevOps
    INFO [03/17/24 13:41:11:92] Found commit ['1beb15c' - Merge branch 'release/12.2.0'] matching merge message format: Default
    INFO [03/17/24 13:41:11:96] Merge message 'Merged PR 323216 from release/12.4.0 into main
Merge': 12.4.0 with commit source '537295368e71b67d86d243ab13b9ac360e60d4da'
    INFO [03/17/24 13:41:11:99] Merge message 'Merge branch 'release/12.2.0'': 12.2.0 with commit source '1beb15cb7224c39f68162586ff0c3a46e1cb6073'
  INFO [03/17/24 13:41:11:99] -< End: [Using 'MergeMessageVersionStrategy' strategy] (Took: 130.38ms) >-

[DSpirit]

@HHobeck

For testing reasons, I've tried to overcome the single IsMergeCommit property validation and added an additional OR statement to validate whether the MergeMessage matches one of the specified MergeMessageFormats in this PR:
#3965

At least for my use case it worked, however I'm way too new into this repository to really make sure it's an appropriate solution.

My main concern is the workaround of the IsMergeCommit check - as already stated in my question above, I don't know the exact reason for the necessity of 2 parent commits in order to acknowledge a commit as a MergeCommit.

As a second approach, I extended the TryParse operation to check whether the mergedBranch is actually a release branch.
This way, I think it's more specific to the outlined use case and covers just the requirement of increments using merged release branches.

#3966

[HHobeck]

My main concern is the workaround of the IsMergeCommit check - as already stated in my question above, I don't know the exact reason for the necessity of 2 parent commits in order to acknowledge a commit as a MergeCommit.

@asbjornu: What is your opinion about this!? Do we need to change the logic and detect arbitrary commits as a merge commit (without multiple parents) as well?

[asbjornu]

I don't really understand the use-case. A commit with only one parent isn't a merge-commit. A "squash merge" isn't a merge, it's a commit. Calling it "merge" is simply invalid and wrong. I also think squashing commits is wrong, but that's a different discussion.

I'm not opposed to adding support to identify squashed commits as special, but that should be its own use-case and strategy, imho.

[DSpirit]

@asbjornu by default, a lot of our Azure DevOps organizations have reduced the valid merge types to squash commits only.
Surely this might not be best practice, but it is what it is and I'm trying to find a solution.

Unfortunately my first PR didn't work out so well with the existing tests, that's why I've created the second one - there is only one test failing due to:
// [TestCase("Merge branch 'hotfix-0.1.5'", false)] -> this is somehow configured as a release branch and I don't know why. That's why I've commented it.

If you'd rather prefer the first one, I would check the failing tests again and come back to you once I'm done.
For me, I guess both ways are working.

[DSpirit]

@asbjornu as I couldn't fix the tests in the first PR, could you please have a look at my message above including this PR: #3966

[DSpirit]

Implemented with #3984, thanks for helping me out here!