GitVersion Build Metadata is not incrementing properly

Question

I'm using Gitversion Task 5.1.2 for AzureDevOps.

My branching strategy is GitFlow.

From the development branch output:

Base version used: Git tag '3.0.0-beta.5': 3.0.0-beta.5 with commit count source 35fb4fe5e51526375e94f61dfc3cca421d235c11 (Incremented: 3.0.0-beta.6)

I was expecting 3.0.0-beta.6, from the line above I can see that it calculated the metadata properly, so far so good, but in the end, the update number was 3.0.0-beta.1, as shown below.

  INFO [11/27/19 19:13:42:97] 1 commits found between 35fb4fe5e51526375e94f61dfc3cca421d235c11 and c6bf7b9b86727f1fcd944dc32d7e34be57e4c0cc
  INFO [11/27/19 19:13:43:00] Begin: Creating dictionary
  INFO [11/27/19 19:13:43:01] End: Creating dictionary (Took: 8.32ms)
  INFO [11/27/19 19:13:43:02] Begin: Storing version variables to cache file D:\a\1\s\.git\gitversion_cache\0DA5D62C7623C962136858D6D06616CC294FEB91.yml
  INFO [11/27/19 19:13:44:07] End: Storing version variables to cache file D:\a\1\s\.git\gitversion_cache\0DA5D62C7623C962136858D6D06616CC294FEB91.yml (Took: 1,053.64ms)
  INFO [11/27/19 19:13:44:43] Applicable build agent found: 'VsoAgent'.
Executing GenerateSetVersionMessage for 'VsoAgent'.
Executing GenerateBuildLogOutput for 'VsoAgent'.
  INFO [11/27/19 19:13:44:45] Updating assembly info files
  INFO [11/27/19 19:13:44:47] Found 1 files
##[section]Async Command Start: Update Build Number
Update build number to 3.0.0-beta.1 for build 4043

My GitVersion.yml

mode: ContinuousDelivery
branches:
  master:
    regex: master
    tag: ''
  release:
    regex: releases?[/-]
    tag: rc
  feature:
    regex: features?[/-]
    tag: alpha
  develop:
    regex: dev(elop)?(ment)?$
    mode: ContinuousDeployment
    tag: beta
ignore:
  sha: []
merge-message-formats: {}

And I'm not understanding why?

Could someone help me, please?

Answer 1

The problem was when the branch release/2.2.0 was merged back to development, in the GitVersion.yml there was the next-version: 3.0.0 tag and the commit count was 5. So GitVersion created the build version number 3.0.0.beta.5. So far, so good, but this merge back somehow reset the commit count.

In the next pull request, the result was that, even though there was not the next-version: 3.0.0 tag anymore, there was already a tag 3.0.0.beta.5 and it had calculated right the increment before, GitVersion chose the 3.0.0 as version number and use the commit count to add the metadata beta.1, to create Update build number to 3.0.0-beta.1

My approach was to change the GitVersion.yml file as follow:

next-version: 3.1.0
mode: ContinuousDelivery
branches:
  master:        
    regex: master    
    tag: ''    
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    tracks-release-branches: false
    is-release-branch: false
  release:
    tag: rc
    tracks-release-branches: false
    is-release-branch: true    
  develop:
    tag: beta
    increment: Minor
    tracks-release-branches: true
    is-release-branch: false
ignore:
  sha: []
merge-message-formats: {}

I use:

• next-version 3.1.0 => force the next build to create the tag 3.1.0.beta.2 instead 3.0.0.beta.2. it was a one-time thing, just to go back to the right track.

• increment => to tell GitVersion which part to increase in each branch, the release default is none;

• tracks-release-branches => to tell GitVersion that the branch is or is not the develop branch in Gitflow strategy

• is-release-branch => to tell GitVersion that the branch is or is not the release branch in Gitflow strategy