Version bump only seems to happen on first branch/commit

[roddharris]

I'm new to GitVersion and am trying to implement SemVer versioning of my NuGet package in Azure Pipelines. At this point, I haven't received permission from my org to install the GitTools utility -- so I'm doing thing a bit more manually.

I've tried the following:

1. I created a repository.
2. I pushed a new project into the repository.
3. I created a tag on the commit of v1.0.0
4. I created a feature branch (feature-ImplementAdd) with one commit - +semver:minor
5. I pushed the branch/commit to remote
6. Build kicks in and semver = 1.1.0-ImplementAdd.1
7. I merge the branch into master
8. Build kicks in and semver = 1.1.0
9. I create a new branch of updated master (feature-ImplementSubtract)
   a. first commit +semver:minor
   b. second commit +semver:patch
   c. third commit +semver:minor
10. I push the branch/commits to remote
11. Build kicks in and semver = 1.1.0-ImplementSubtract.1

Steps 1 - 8 all seem to be what I would expect from all the documentation and examples. However, steps 9 - 11 are where I get confused. In my mind, semver in step 11 should be 1.3.0-ImplementSubtract.1 or at least 1.2.0-ImplementSubtract.1. IOW, The minor version should be incremented.

Here is the output of the GitVersion variables from the build in step 11:

Again, I'm new to GitVersion so maybe I'm not fully understanding how to use it. Could someone help me determine if I'm doing something wrong or if GitVersion just is not working correctly in my environment?

Update

Based on other answers (and the fact that I use GitHubFlow, I changed my gitversion.yaml to the following (unfortunately, I get the same results).

new gitversion.yaml

workflow: GitHubFlow/v1

original gitversion.yaml

mode: mainline
tag-prefix: '[vV]'
commit-message-incrementing: Enabled
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)'
assembly-informational-format: '{Major}.{Minor}.{Patch}' 
update-build-number: true

branches:
  main:
    regex: ^(master|main)$
    is-main-branch: true
    is-source-branch-for: ['feature', 'bugfix']
  feature:
    regex: ^feature?[/-]
    source-branches: ['main']
    tag: feat-{BranchName}
    increment: Minor
  bugfix:
    regex: ^bugfix?[/-]
    source-branches: ['main']
    tag: bugfix-{BranchName}
    increment: Patch
ignore:
    sha: []
merge-message-formats: {}

azure-pipelines.yaml

name: '1.0.$(Rev:r)'
variables:
  buildConfiguration: 'Release'
  projectPath: '**/NugetTestLib/NugetTestLib.csproj'
  projectName: 'NuGet Test Library'
    
pool:
  name: 'Azure Pipelines'

stages:
- stage: BetaVersioning
  displayName: 'Build Beta Version Number'
  jobs:
  - job: BetaVersion
    steps:
    - checkout: self
      fetchDepth: 0
    - script: 'dotnet tool install --global GitVersion.Tool --version 5.*'
      displayName: 'GitVersion Install'
    - script: 'dotnet-gitversion /config ./GitVersion.yml'
      displayName: 'Print GitVersion variables'

    - task: PowerShell@2
      displayName: 'Determine version with GitVersion'
      inputs:
        targetType: 'inline'
        script: |
          $output = dotnet-gitversion /config ./GitVersion.yml | ConvertFrom-Json
          $output.PSObject.Properties | ForEach-Object {
            echo "##vso[task.setvariable variable=GitVersion.$($_.Name)]$($_.Value)"
          }
 
    - script: echo $(GitVersion.SemVer)
      displayName: 'Display New Build Version'

    - task: Bash@3
      displayName: Update pipeline build number
      inputs:
        targetType: inline
        script: echo "##vso[build.updatebuildnumber]$(GitVersion.SemVer)"        

 
You can see a full description of my issue on StackOverflow.

[HHobeck]

The mainline version strategy is a new algorithm but can be seen as a equivalent to the previous Mainline mode:

workflow: GitHubFlow/v1
strategies:
- ConfiguredNextVersion
- Mainline

And step 13 should yield 2.2.1

Why should it? GitVersion aggregates the minor and patch bump message to just minor.

[roddharris]

:-) I guess that was part of my question -- I'm not entirely sure how GitVersion works. Are you saying that step 13 should've yielded 2.2.0? (Sorry, I didn't see that you had posted before updating my original post -- my update tried to simplify things). I will try adding the strategies that you've listed and see what happens.

[HHobeck]

:-) I guess that was part of my question -- I'm not entirely sure how GitVersion works. Are you saying that step 13 should've yielded 2.2.0?

Of course it depends also what the increment of your branch is. If you use lets say a branch where the increment is set to major then the major increment wins. Anyway in your example 2.2.0 is expected because the feature branch inherits the increment from main which is patch.

Please see following discussion:

• I'm having issues with the message version bump. #3933

[roddharris]

@HHobeck , The discussion link you provided was helpful -- thank you.

I added the strategies that you listed above directly to the main branch and commited with +semver:major. As expected, my build now used semver of 2.0.0 (was 1.1.0).

However, I then branched from master (feature-ImplementMultiply), made a change and commited with +semver:minor. When I push the branch, the build kicks off and GitVersion shows the semver as 2.0.0. Based on my the GitHubFlow defaults and the discussion thread you pointed me to, I would've expected 2.1.0. Am I looking at this wrong?

GitVersion variables from the feature build

[HHobeck]

This test is green:

  public void IssueTest()
  {
      IGitVersionConfiguration mainline = GitHubFlowConfigurationBuilder.New
          .WithVersionStrategy(VersionStrategies.Mainline)
          .Build();

      using var fixture = new EmptyRepositoryFixture("main");

      fixture.MakeATaggedCommit("1.0.0");
      fixture.MakeACommit("+semver: minor");
      fixture.AssertFullSemver("1.1.0-1", mainline);

      fixture.BranchTo("feature/foo");
      fixture.AssertFullSemver("1.1.1-foo.1+0", mainline);

      fixture.MakeACommit("+semver: minor");
      fixture.AssertFullSemver("1.2.0-foo.1+1", mainline);

      fixture.MergeTo("main");
      fixture.AssertFullSemver("1.2.0-2", mainline);

      fixture.MakeACommit("+semver: major");
      fixture.AssertFullSemver("2.0.0-1", mainline);

      fixture.BranchTo("feature/bar");
      fixture.AssertFullSemver("2.0.1-bar.1+0", mainline);

      fixture.MakeACommit("+semver: minor");
      fixture.AssertFullSemver("2.1.0-bar.1+1", mainline);
  }

[roddharris]

@HHobeck So it looks like it works for you, but you can see my GitVersion variables are clearly not the same as what you're showing. So I'm trying to figure out why it doesn't work in my scenario. My configuration is VERY minimal -- mostly using GitHubFlow defaults so I can't understand why my minor version is not incrementing.

My git tree/commits looks almost identical:

This is my entire gitversion.yml file:

workflow: GitHubFlow/v1
strategies:
- ConfiguredNextVersion
- Mainline

One difference I see is your feature branches are created as feature/foo instead of feature-foo but it seems like I recall that the default regex looks for either.

[HHobeck]

The problem is that GitVersion does not consider the merge commit message Merged PR 21331: Implement Add feature as a merge message.

The reason why is documented here:

• Mainline Not Incrementing SemVer when merging to main with AzureDevops #3800

Following screenshot shows the allowed patterns:

[roddharris]

@HHobeck Not doubting you -- that may be part of the problem I'm having. However, I just committed directly to main with a commit message of +semver:minor and pushed the commit, the build number still computed to 2.0.0 -- not 2.1.0. Would the PR issue be affecting a direct commit like that as well? Is this a case where once things get out of sync (i.e. the PR issue) then nothing works right after that or should bump messages on my commit still work?

Also, if I don't Squash my commits, would the PR message still be necessary since each commit with its bump message is being directly committed to the main branch when I merge my PR?

[roddharris]

Changing the workflow did not help.

Both of these commits were against master. Using master instead of main should be fine correct? (Seems like regex accounts for both, but I wasn't sure if there was other config that maybe relied on main instead of master).

[roddharris]

Okay, I'm confused. I'm currently using the workflow: TrunkBased/preview1 as you suggested.

On the latest commit of master, I added a new tag v3.0.0. That should kind of "reset" things to a clean state.
Then I did a commit directly on master with +semver:minor. The build showed 3.1.0 exactly as I expected.
Then I did a second commit directly on master with +semver:minor. The build showed 3.1.0 -- I expected 3.2.0.

Is my expectation off or is this not expected behavior?

Edit
Changed the workflow back to workflow: GitHubFlow/v1 and added a new tag v4.0.0. Did the exact steps above and got the same results -- both builds yield 4.1.0

[HHobeck]

May I ask you how you are creating your test case? Are you editing the commit message somehow? I assum that the merge message commit has a wrong time stamp and will be interpreted in a wrong order.

Can you please provide the git commands so I can reporuce it on my machine (without azure devops)?

[roddharris]

I'm not really using test cases. I'm using Visual Studio and Azure Pipelines. I do the commits using the VS IDE and push those commits to Azure Devops repo also using the VS IDE. Once the commits/branches are pushed to Azure Devops, I perform the Pull Requests and Merges in Azure Devops.

[roddharris]

I'll see if I can translate the VS actions into git commands and list out exactly what steps I'm taking.

[roddharris]

Here are my most recent steps:

1. git tag -a v6.0.0 -m v6.0.0 -- tag latest commit on master
2. git push origin v6.0.0 -- ensure tag is on remote
3. [ modified a file ]
4. git commit -a -m "+semver:minor Test of minor update direct on master" -- expect semver of 6.1.0
5. git push -- push commit to remote
6. [ build pipeline: semver = 6.1.0 as expected ]
7. [ modify another file ]
8. git commit -a -m "+semver:minor Test 2 of minor update direct on master" -- expect semver of 6.2.0
9. git push -- push commit to remote
10. [ build pipeline: semver = 6.1.0 NOT expected ]

I've removed branching and merging completely from the equation. All git commands were directly from the command line and directly on master branch -- not through VS.

As far as the time stamps, here are what I see for the timestamp on the remote (Azure Devops).

[roddharris]

@HHobeck just curious, as I said in my initial post, I'm trying to use GitVersion in Azure DevOps without using GitTools. (I still have not received approval from the company to install it). I'm curious if maybe there are items I need to tweak or do differently when not using GitTools -- maybe things that GitTools does behind the scenes that I may not be doing?

[HHobeck]

I'm curious if maybe there are items I need to tweak or do differently when not using GitTools -- maybe things that GitTools does behind the scenes that I may not be doing?

I don't understand. What do you mean with that!? You asking about an alternative to GitVersion?

[roddharris]

I don't understand. What do you mean with that!? You asking about an alternative to GitVersion?

Sorry, no, I'm not looking for an alternative to GitVersion. There is an extension that can be installed in the Azure environment called GitTools. My understanding is that GitTools is a wrapper over top of GitVersion that makes using GitVersion in Azure a bit easier. Most examples I've seen of using GitVersion with Azure Pipelines involves GitTools.

Since I haven't seen many examples of people using GitVersion directly in Azure Pipelines, I was wondering if GitTools adds some kind of extra GitVersion config that I'm missing when configuring manually that enables GitVersion to work well with Azure DevOps.

I'm guessing that if you run the exact steps I listed above with the same GitVersion configuration, it will work for you. The biggest difference is probably that you're not running within Azure Devops environment.

At this point, I'm just grasping at straws trying to figure out why I can't get GitVersion to function as expected in my Azure DevOps environment.

[roddharris]

@HHobeck were you able to re-create the issue I'm having given my "most recent steps" post from last week? I'm just wondering if you might have any more ideas as to why this is not working for me? Are there other things that I can try? Should I open an issue for this?

Thanks

[HHobeck]

I did get the same result using:

workflow: TrunkBased/preview1

Does that one use Mainline?

Please find the configuration at the following location:
https://github.com/GitTools/GitVersion/blob/main/docs/input/docs/workflows/TrunkBased/preview1.yml

[HHobeck]

Maybe in the pipeline the wrong configuration is used.

[roddharris]

@HHobeck , here is my complete azure-pipelines.yml for defining my pipeline. Is there anything in there that would force GitVersion to use the wrong configuration?

variables:
  buildConfiguration: 'Release'
  projectPath: '**/Test.CalculatorLib/Test.CalculatorLib.csproj'
  projectName: 'NuGet Test Calculator Library'
  
pool:
  name: 'Azure Pipelines'

stages:
- stage: BetaVersioning
  displayName: 'Build Beta Version Number'
  jobs:
  - job: BetaVersion
    steps:
    - checkout: self
      fetchDepth: 0
    - script: 'dotnet tool install --global GitVersion.Tool --version 5.*'
      displayName: 'GitVersion Install'
    - script: 'dotnet-gitversion /config ./GitVersion.yml'
      displayName: 'Print GitVersion variables'

    - task: PowerShell@2
      displayName: 'Determine version with GitVersion'
      inputs:
        targetType: 'inline'
        script: |
          $output = dotnet-gitversion /config ./GitVersion.yml | ConvertFrom-Json
          $output.PSObject.Properties | ForEach-Object {
            echo "##vso[task.setvariable variable=GitVersion.$($_.Name)]$($_.Value)"
          }
 
    - script: echo $(GitVersion.SemVer)
      displayName: 'Display New Build Version'

    - task: Bash@3
      displayName: Update pipeline build number
      inputs:
        targetType: inline
        script: echo "##vso[build.updatebuildnumber]$(GitVersion.SemVer)"        

[arturcic]

• script: 'dotnet tool install --global GitVersion.Tool --version 5.*'

Please use version 6.*

[roddharris]

@arturcic using version 6.* definitely improved my results. I'm still unsure if I should be using workflow: Trunkbased/preview1 or workflow:GitHubFlow/v1. My actual workflow definitely lines up with GitHubFlow -- i.e. master is my current branch, features are branched from master, committed and merged back into master.

Also, I'm a little unsure of two other things:

1. Does the merge message matter? If I branch from master (currently at 9.0.0) into a branch called feature-My New Feature, when I push the feature branch into the repo, I get a build of #9.1.0-My New Feature.1. When I create a PR and merge, does my PR message need to be something specific or should the merge cause master to build to #9.1.0?
2. Does the type of merge matter? Do I need to perform a Squash merge or can I do Merge (no fast forward)?