[Bug] Tag checkout on GitHub Actions generates unexpected branch

We have a GitHub Action that triggers on tag push. When it runs, GitVersion generates a version like this: 1.3.0-tags-1-2-1.1+6. The 1.2.1 tag is defined on the tip of the release-1.2 branch.

When I run GitVersion locally, it generates the expected version 1.2.1. When I configure my local environment to replicate the GitHub Actions environment, I do get the same incorrect version number.

Expected Behavior

When checking out a tag in GitHub actions that relates to a version number, that version number should be generated.

> git branch
* (HEAD detached at 1.2.1)

> dotnet-gitversion
{
  // ...
  "SemVer": "1.2.1"
  // ...
}

Actual Behavior

Normalization and checking out the GITHUB_REF as a branch is causing an unexpected branch to be created and checked out and that is giving us an incorrect version number.

> git branch
* (HEAD detached at 1.2.1)

> SET GITHUB_ACTIONS=true

> SET GITHUB_REF=refs/tags/1.2.1

> dotnet-gitversion
{
  // ...
  "SemVer": "1.3.0-tags-1-2-1.1"
  // ...
}

> git branch
  master
  release-1.0
  release-1.2
  release-1.3
* tags/1.2.1

Possible Fix

The GITHUB_REF environment variable is set to the tag ref (i.e. refs/tags/1.2.1) but this gets treated like a branch name. Ultimately this ref gets mangled into a canonical name like this refs/heads/tags/1.2.1, and turned into a branch named tags/1.2.1. This branch name is used in the SemVer version.

Steps to Reproduce

NOTE: The repo experiencing this issue is this one.

This is the cmd script that I have used to reproduce this locally

@REM Pretending to be GitHub Actions
set GITHUB_ACTIONS=true
set GITHUB_REF=refs/tags/1.2.1

@REM Simulate actions/checkout@v2.3.4 with fetch-depth 0
git init .
git remote add origin https://github.com/Particular/NServiceBus.AzureFunctions.InProcess.ServiceBus
git -c protocol.version=2 fetch --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/*
git checkout --progress --force refs/tags/1.2.1

@REM Build
dotnet build src --configuration Release

Context

Your Environment

• Version Used: 5.6.9 (also tested with 5.7.0+Branch.main.Sha.8d177c6d666c8eeb1c6a6a2c71fd4b78741137d21 as installed global tool)
• Operating System and version (Windows 10, Ubuntu 18.04): GitHub Actions with windows-2019
• Link to your project: https://github.com/Particular/NServiceBus.AzureFunctions.InProcess.ServiceBus
• Link to your CI build (if appropriate): https://github.com/Particular/NServiceBus.AzureFunctions.InProcess.ServiceBus/blob/release-1.2/.github/workflows/release.yml

[mikeminutillo]

I did a little more digging and I think I can narrow down the cause. When normalization puts us on a tags/... branch, we don’t have a matching branch configuration, so it creates the default one and inherits from main. Our main config tracks release branches. That means, even though our tag is on a release branch, it gets applied on top of all of the other release branches and then the wrong one is selected.

I will try and put together a minimal test to prove that this is what is happening.

If this is what it is, we may be able to keep normalization by having an explicit branch configuration for tags/....

[ausarb]

This appears to have been broken sometime between 5.10.0 and 5.12.0. I’ve had to lock in GitVersion to 5.10.0 to keep this fix.

- name: Install GitVersion
  uses: gittools/actions/gitversion/setup@v0.9.15
  with:
    # v5.10.0 of GitVersion has a fix for incorrect versions when building tags. See https://github.com/GitTools/GitVersion/issues/2838
    # It appears that the fix then had a regression in a later version, so locking in 5.10.0.  See https://github.com/GitTools/GitVersion/issues/3351#issuecomment-1403657689
    versionSpec: '5.10.0'