First version after tag push has patch equal to 1 and not 0. Why?

Question

I am using GitVersion with Github Actions with main branch.

When a new tag is pushed to main branch, e.g. v2.0.0, I want to increase the patch:

2.0.0, 2.0.1, 2.0.2, ...

I have the following Github workflow:

name: Project
    
on:
  push:
    branches: [ main ]

jobs:

  setup:

    runs-on: ubuntu-latest

    outputs:
      version: ${{ steps.versioning.outputs.semVer }}

    name: setup

    steps: 

      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Dotnet
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.x'
 
      - name: GitVersion
        uses: gittools/actions/gitversion/setup@v1
        with:
          versionSpec: '5.x'

      - name: Versioning
        uses: gittools/actions/gitversion/execute@v1
        id: versioning
          
  build:

      // Remaining workflow code

And I also have the gitversion.yml settings file:

mode: Mainline
branches:
  main:
    regex: ^main$
    mode: Mainline
    increment: Patch
    is-mainline: true

And this is where the files are located in my project root:

Question

I pushed the tag v2.0.0 and after it I pushed the code to main branch.

The first version I got was 2.0.1 ... Why not 2.0.0?

I also tried to push the tag v2.0 but the first version is always 2.0.1.

Why? Is there a way to make 2.0.0 the first version after pushing the tag?

Answer 1

As I just mentioned on your previous question, the GitVersion config file default name is GitVersion.yml, not gitversion.yml.

In your case, it is best to specify the full path (from the root of your repository)

steps:
  # gittools/actions/gitversion/[email protected] action omitted for brevity.

  - name: Determine Version
    uses: gittools/actions/gitversion/[email protected]
    with:
      useConfigFile: true
      configFilePath: myVersionConfig.yml

Here that would mean a myVersionConfig.yml in the root folder.

To achieve 2.0.0 as the first version after pushing the tag, you would need to make sure the commit triggering the version calculation is the same commit the tag points to, or you would need to reconsider the workflow to adjust when and how you apply tags versus when you expect version increments.

Maybe pushing the commit and tag together would help. (git push --atomic origin <branch name> <tag>).