Assistance needed: How to configure my develop branch to track merges

[CJCombrink]

Hi,

Our workflow I am trying to replicate with GitVersion is summed up as follow:

1. development is done on the development branch
   1. label is 'rc'
2. releases are done for each commit on release/ branches
   1. Each commit to the release branch is a patch step
3. features and bugfixes are done on the respective branches
4. development should step version based on the type of branch merged
   1. feature steps minor
   2. bugfix steps patch
   3. major is controlled using commit messages
5. development must always step the minor after a release is made and merged back

I have a configuration that works if I tag my rc version on the development branch after a merge.
If I don't tag the release the versions are not calculated correctly from the base version, the merges to development is not taken into account when new branches are made.

I am not sure if that is the correct behaviour or if my configuration is incorrect.

GitVersion.yml

workflow: GitFlow/v1
assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatch
tag-prefix: '[vV]?'
version-in-branch-pattern: (?<version>[vV]?\d+(\.\d+)?(\.\d+)?).*
major-version-bump-message: \+semver:\s?(breaking|major)
minor-version-bump-message: \+semver:\s?(feature|minor)
patch-version-bump-message: \+semver:\s?(fix|patch)
no-bump-message: \+semver:\s?(none|skip)
tag-pre-release-weight: 60000
commit-date-format: yyyy-MM-dd
merge-message-formats: {}
update-build-number: true
semantic-version-format: Strict
strategies:
- Fallback
- ConfiguredNextVersion
- MergeMessage
- TaggedCommit
- TrackReleaseBranches
- VersionInBranchName
branches:
  develop:
    mode: ContinuousDelivery
    label: rc
    increment: Minor
    prevent-increment:
      when-current-commit-tagged: true
    track-merge-target: true
    track-merge-message: true
    regex: ^development$
    is-source-branch-for: []
    tracks-release-branches: true
    is-release-branch: false
    is-main-branch: true
    pre-release-weight: 0
  release:
    mode: ContinuousDeployment
    label: ''
    increment: Patch
    prevent-increment:
      of-merged-branch: true
      when-current-commit-tagged: true
    track-merge-target: false
    regex: ^release/
    source-branches:
    - develop
    is-source-branch-for: []
    tracks-release-branches: true
    is-release-branch: true
    is-main-branch: false
    pre-release-weight: 30000
  feature:
    mode: ContinuousDelivery
    label: 'alpha'
    increment: Minor
    prevent-increment:
      when-current-commit-tagged: false
    track-merge-message: true
    regex: ^feature/
    source-branches:
    - develop
    - release
    is-source-branch-for: []
    is-main-branch: false
    pre-release-weight: 30000
  bugfix:
    mode: ContinuousDelivery
    label: 'alpha'
    increment: Patch
    prevent-increment:
      when-current-commit-tagged: false
    track-merge-message: true
    regex: ^bugfix/
    source-branches:
    - develop
    - release
    is-source-branch-for: []
    is-main-branch: false
    pre-release-weight: 30000
  pull-request:
    mode: ContinuousDelivery
    label: 'beta'
    increment: Inherit
    prevent-increment:
      of-merged-branch: true
      when-current-commit-tagged: false
    label-number-pattern: '-(?<number>\d+)'
    track-merge-message: true
    regex: ^PR-
    source-branches:
    - develop
    - feature
    is-source-branch-for: []
    pre-release-weight: 30000
  unknown:
    mode: ManualDeployment
    label: '{BranchName}'
    increment: Inherit
    prevent-increment:
      when-current-commit-tagged: true
    regex: (?<BranchName>.+)
    source-branches:
    - develop
    - release
    - feature
    - pull-request
    is-source-branch-for: []
    is-main-branch: false
ignore:
  sha: []
mode: ContinuousDelivery
label: '{BranchName}'
increment: Inherit
prevent-increment:
  of-merged-branch: false
  when-branch-merged: false
  when-current-commit-tagged: true
track-merge-target: false
track-merge-message: true
commit-message-incrementing: Enabled
regex: ''
source-branches: []
is-source-branch-for: []
tracks-release-branches: false
is-release-branch: false
is-main-branch: false

A short summary of the steps

git init && git commit
do_tag '0.0.0'
assert_version "0.0.0"

# feature/*
do_branch "feature/test_1"
assert_version "0.1.0-alpha.0"
do_commit
assert_version "0.1.0-alpha.1"
do_commit
assert_version "0.1.0-alpha.2"

# Simulate a PR
do_branch "PR-1"
assert_version "0.1.0-beta1.2"

log_info "Testing merge: feature/*"
do_checkout "development"
assert_version "0.0.0"
do_merge "feature/test_1"
assert_version "0.1.0-rc.3"
# do_tag "$(gitversion /v semver)" # THIS DOES NOT BELONG HERE

# bugfix/*
log_info "Testing branch: bugfix/*"
do_branch "bugfix/test_1"
assert_version "0.1.0-alpha.3" 

The last assert_version fails, GitVersion reports '0.0.1-alpha.3'

When I make the tag at the # THIS DOES NOT BELONG HERE mark the version is correct in the branch.

PS: I wrote a bash script to simulate the unit tests of this project and can provide that if it will help

[HHobeck]

I have already answered this question and gave to you the information that the track-merge-message feature you are expecting is only supported in the TrunkBased/preview1 workflow.

#4217 (comment)

Generally we cannot helping out with custom workflows. But if you want you can engage me or other person to help you and build custom workflows.

Thank you for your understanding.

[CJCombrink]

@HHobeck Thank you for the answer.

I have already answered this question

Sorry, my intention was not to repeat the same question: I used your answer from #4217 as the input to my current configuration file to get the branch name to correctly affect the version increments.

This question, in my head at least, refers to avoiding the intermediate tags (*-foo-* and *-bar-* in your test and *-rc-* in mine) if possible.
I think my confusion comes from the track-merge-message mentioned since I don't rely on the message, but instead the "track-merge-branch" aspect.

I am still not following the following comments and the posted screenshot in the linked answer

I don't see any reason why not implementing it in the MergeMessage version strategy as well:
Please notice that the Mainline version strategy can be seen as a single version strategy which might be not compatible with others.

But I think that is not important at this point, my question at least seems to be answered between these two discussions.

Again, thanks for the tool and the response. By having the intermediate tags I can at least achieve the workflow that I desire, at the expense of more tags (tags are cheap at least)