track-merge-target in branch config not working

[rose-a]

I'm trying to create a GitVersion config for GitLab Flow.

In GitLab Flow master is effectively the development branch and the production branch resembles master in Git Flow.

Since GitLab allows the automatic creation of issue branches from within its GUI (branch name starting with the GitLab issue number), I created a new branch type for them borrowing the feature branch config.

The resulting config looks like this:

mode: ContinuousDeployment
branches:
  master:   
    tag: alpha
    regex: ^master$
    increment: Minor
    prevent-increment-of-merged-branch-version: false
    track-merge-target: true
    tracks-release-branches: true
    is-release-branch: false
    is-mainline: false
    source-branches: []
  production:
    tag: ''
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    regex: ^production$
    source-branches:
    - master
    - develop
    - release
    tracks-release-branches: false
    is-release-branch: false
    is-mainline: true
  issue:
    tag: issue-{BranchName}
    increment: Inherit
    prevent-increment-of-merged-branch-version: false
    regex: ^(?=\d+-)
    source-branches:
    - master
    - develop
    - feature
    - hotfix
    - support
    - issue
    - production
ignore:
  sha: []

The one thing which is currently not working is track-merge-target: true on the master branch config, which, according to the docs should do the following:

track-merge-target

Strategy which will look for tagged merge commits directly off the current branch. For example develop → release/1.0.0 → merge into master and tag 1.0.0. The tag is not on develop, but develop should be version 1.0.0 now.

So with the provided config I would expect master → merge into production and tag 1.0.0 to result in master incrementing to 1.1.0 on the next commit.

Do I understand the intention of the track-merge-target setting correctly?

PS: Trying to understand the behaviour from the source code I stumbled upon the following:

So basically the setting is read but never used! Is this feature actually implemented?

[stale]

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. Thank you for your contributions.

[rose-a]

Can anybody help with this?

[asbjornu]

Sorry, but you may have stumbled across a bug here. If you are able to submit a pull request that fixes the bug, we will of course merge it, but I don't have time to look at this anytime soon, I'm afraid.

[stale]

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. Thank you for your contributions.

[rose-a]

Maybe don't let it auto-close and track this as a bug so it might get implemented someday in the future?

[arturcic]

@rose-a The only way we can get this one fixed is when someone will send us a PR we can review and merge, unfortunately we don't have too much time to fix it so a PR from your side it welcomed.

[rose-a]

@arturcic yeah I get that, no pressure... but just letting it go stale and auto-close won't fix things... don't know how you can tell your stale bot to leave it alone, maybe by adding a bug label or something 😉

[asbjornu]

@rose-a, yes, I've been thinking about doing that for a while. Thanks for reminding me. #2135 created to do just that. :)

[L-U-C-K-Y]

Thanks for this issue, I have also been looking for quite some time for a tool that supports GitLab Flow.

Can someone point us in the right direction where we have to take a look?

Strategy which will look for tagged merge commits directly off the current branch.

I'm not experienced in C#, but are we looking at the GetTaggedVersions function that should take the current branch with the track-merge-target option set?

GitVersion/src/GitVersionCore/VersionCalculation/BaseVersionCalculators/TaggedCommitVersionStrategy.cs

Line 29 in e1b4534

internal IEnumerable<BaseVersion> GetTaggedVersions(Branch currentBranch, DateTimeOffset? olderThan)

[dxynnez]

I think I am hitting the same problem...

I am testing the behavior locally with:

next-version: 3.0.0
branches
  TestRelease:
    regex: ^TestRelease$
    is-mainline: true
    source-branches: [ 'TestDevelop' ]
    mode: ContinuousDelivery
    tag: ''
    increment: Minor
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    tracks-release-branches: false
    is-release-branch: true
  TestDevelop:
    regex: ^TestDevelop$
    is-mainline: false
    source-branches: [ ]
    mode: ContinuousDelivery
    tag: beta
    increment: Patch
    prevent-increment-of-merged-branch-version: false
    track-merge-target: true
    tracks-release-branches: true
    is-release-branch: false

TestDevelop & TestRelease are on 3.0.0 and I then merge a new commit from TestDevelop into TestRelease branch with a merge commit (no-ff). Then I tag the merge commit with a new version number 3.1.0

According to the doc:

track-merge-target
Strategy which will look for tagged merge commits directly off the current branch. For example develop → release/1.0.0 → merge into main and tag 1.0.0. The tag is not on develop, but develop should be version 1.0.0 now.

I was expecting TestDevelop to start from 3.1.0 at this point, but adding another new commit to TestDevelop and run gitversion still give me 3.0.1, which, didn't seem to honor the tag on the merge commit.

Did I just misunderstand the doc or it's indeed a bug? @asbjornu is there any insight you can share on this? I am more than happy to submit a PR to fix it if you can point me to a start point.