GitVersion: [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

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 16 (10 by maintainers)

Commits related to this issue

Most upvoted comments

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/....