[Bug] Tag checkout on GitHub Actions generates unexpected branch

[mikeminutillo]

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/[email protected] 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

[asbjornu]

Thanks for the reproduction. Otherwise, this seems like a duplicate of #2301.

[timbussmann]

FYI (for anybody else running into this): Since this only happens with the repo normalization (therefore running on a build agent) enabled, we've currently worked around this by disabling repo normalization. As we're using the msbuild tasks, the normalization can be disabled by specifying <GitVersion_NoNormalizeEnabled>true</GitVersion_NoNormalizeEnabled> (we added this to a Directory.Build.props).

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

[sbarfurth]

This also happens when GITLAB_CI and CI_COMMIT_REF_NAME is set. The calculated version is then also wrong. This can be reproduced as stated above. Exact same detached HEAD for a tag with the above variables set and unset. With them unset the correct version is generated, with them set the version is incorrect and a branch is created that is named the same as the value of CI_COMMIT_REF_NAME. When using -nonormalize the version calculated is still incorrect but the the errand branch is not generated.

[danielmarbach]

When using 5.8.1 instead of 5.6.11 this problem seems to be fixed.

[arturcic]

When using 5.8.1 instead of 5.6.11 this problem seems to be fixed.

@mikeminutillo can you confirm the same?

[ThomasPiskol]

I'm facing this bug with 5.8.1 using the MSBuild integration, but it's also reproducible with the command line tool.

What I noticed is, that it only happens if I use Mainline mode. In case of ContinuousDelivery or ContinuousDeployment the version is calculated correctly.

Sample GitHub CI:

• Mainline
• ContinuousDelivery
• ContinuousDeployment

[asbjornu]

@ThomasPiskol, thanks for the reproduction! You write that you're able to also reproduce with the command line. Can you please add that or change your current reproduction from the MSBuild task to the command line? That way it's going to be much easier to test locally.

[asbjornu]

I tested the following command in a clone of this repository just now and was unable to reproduce the problem:

rm -rf .git/gitversion_cache
GIT_BRANCH=main GITHUB_ACTIONS=true gitversion -verbosity verbose -l gitversion.log
cat gitversion.log

If someone are able to concoct a series of commands that can reproduce the problem, I'm more than willing to execute those commands locally and debug what's going on. But until a reliable reproduction exists, I can't be of much assistance, I'm afraid. 🤷🏼‍♂️

[ThomasPiskol]

The crucial environment variable is GITHUB_REF. If this variable is set, the behaviour can be reproduced:

rm -rf .git/gitversion_cache
GITHUB_REF=refs/tags/1.2.1 GIT_BRANCH=main GITHUB_ACTIONS=true gitversion -verbosity verbose -l gitversion.log
{
  "Major": 0,
  "Minor": 7,
  "Patch": 1,
  "PreReleaseTag": "tags-1-2-1.1",
  "PreReleaseTagWithDash": "-tags-1-2-1.1",
  "PreReleaseLabel": "tags-1-2-1",
  "PreReleaseLabelWithDash": "-tags-1-2-1",
  "PreReleaseNumber": 1,
  "WeightedPreReleaseNumber": 1,
  "BuildMetaData": null,
  "BuildMetaDataPadded": "",
  "FullBuildMetaData": "Branch.tags-1.2.1.Sha.e5973747dacb5fb6aa85c8d98d5879f781f0e3a2",
  "MajorMinorPatch": "0.7.1",
  "SemVer": "0.7.1-tags-1-2-1.1",
  "LegacySemVer": "0.7.1-tags-1-2-1-1",
  "LegacySemVerPadded": "0.7.1-tags-1-2-1-0001",
  "AssemblySemVer": "0.7.1.0",
  "AssemblySemFileVer": "0.7.1.0",
  "FullSemVer": "0.7.1-tags-1-2-1.1",
  "InformationalVersion": "0.7.1-tags-1-2-1.1+Branch.tags-1.2.1.Sha.e5973747dacb5fb6aa85c8d98d5879f781f0e3a2",
  "BranchName": "tags/1.2.1",
  "EscapedBranchName": "tags-1-2-1",
  "Sha": "e5973747dacb5fb6aa85c8d98d5879f781f0e3a2",
  "ShortSha": "e597374",
  "NuGetVersionV2": "0.7.1-tags-1-2-1-0001",
  "NuGetVersion": "0.7.1-tags-1-2-1-0001",
  "NuGetPreReleaseTagV2": "tags-1-2-1-0001",
  "NuGetPreReleaseTag": "tags-1-2-1-0001",
  "VersionSourceSha": "4525bf0363e9ea47ded9bbc9ba42d8163262c25b",
  "CommitsSinceVersionSource": 1,
  "CommitsSinceVersionSourcePadded": "0001",
  "UncommittedChanges": 0,
  "CommitDate": "2022-01-15"
}

I'm not sure what the proper solution in this case is. According to the GitHub documentation, the GITHUB_REF environment variable does not always contain a branch name:

The branch or tag ref that triggered the workflow run. For branches this is the format refs/heads/<branch_name>, for tags it is refs/tags/<tag_name>, and for pull requests it is refs/pull/<pr_number>/merge. This variable is only set if a branch or tag is available for the event type. For example, refs/heads/feature-branch-1.

What came to my mind is to change the GitHubActions class. Currently the it's always returning the value of the GITHUB_REF:

GitVersion/src/GitVersion.Core/BuildAgents/GitHubActions.cs

Line 53 in 19462e1

public override string? GetCurrentBranch(bool usingDynamicRepos) => Environment.GetEnvironmentVariable("GITHUB_REF");

)

If GITHUB_REF contains a tag or pull request reference this method could return null instead:

public override string? GetCurrentBranch(bool usingDynamicRepos)
{
    string githubRef = Environment.GetEnvironmentVariable("GITHUB_REF");
    if(githubRef != null && githubRef.StartsWith("refs/heads/"))
    {
        return githubRef;
    }
    return null;
}

Because in this case ResolveCurrentBranch in GitPrepare is able to handle a null value:

GitVersion/src/GitVersion.Core/Core/GitPreparer.cs

Line 84 in 19462e1

var currentBranch = this.buildAgent.GetCurrentBranch(isDynamicRepository) ?? targetBranch;

@asbjornu What do you think? If this the correct way, I can prepare a PR with this change and some additional test to ensure the correct behaviour.

[gep13]

We went through some similar trial and error when trying to grab information from GitHub Actions for the Cake.Recipe project. We ended up using the following:

https://github.com/cake-contrib/Cake.Recipe/blob/9ea449d1868455230dddd236f528edb62cb349ef/Source/Cake.Recipe/Content/github-actions.cake#L21-L83

It isn't perfect, but it fits that needs that we had. There are times when we had to fallback to using git directly to grab the necessary information, since it simply wasn't available in the environment variables presented by GitHub Actions.

[asbjornu]

That seems to be exactly what's going on, @ThomasPiskol. I think your proposed fix is going to be sufficient too. Now, we just need to figure out how to reproduce this in a test so we're sure this bug never pops up again in the future.

[github-actions]

🎉 This issue has been resolved in version 5.10.0 🎉
The release is available on:

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot 📦🚀

[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/[email protected]
  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' 

[dennisdoomen]

I can confirm that this problem happens again with 5.12. After downgrading to 5.10, it resolved itself.

[david-driscoll]

#3085 reverted all the changes from #3033 however some of them still look like they would be beneficial. (not the AzureDevops ones because of the errors of course).

[IT-VBFK]

Can it be, that in 6.0.x this is a thing again?

Reproduce locally:

• git tag 1.1.0 on a commit
• git tag 1.1.1 on a later commit
• git checkout 1.1.1
• dotnet gitversion
• semver is 1.2.0--no-branch-.1 (locally) and 1.2.0-1-1-1.1 (on gitlab-ci) instead of 1.1.1

[asbjornu]

@IT-VBFK, yes. I believe it's related to #4212.