[ISSUE]: GitVersion crashes in GitHub Actions when an action is dispatched on a tag

[asbjornu]

Prerequisites

• [X] I have written a descriptive issue title
• [X] I have searched issues to ensure it has not already been reported

GitVersion package

GitVersion.Tool

GitVersion version

6.0.2

Operating system

Linux

What are you seeing?

Related to #2074, #2456, #4015, and #4183; when a GitHub Action with on: workflow_dispatch is manually started in the GitHub UI by building a specific tag, GitVersion crashes:

INFO [24-09-18 9:18:18:90] Working directory: /home/runner/work/…/…
INFO [24-09-18 9:18:19:01] Project root is: /home/runner/work/…/…/
INFO [24-09-18 9:18:19:01] DotGit directory is: /home/runner/work/…/…/.git
INFO [24-09-18 9:18:19:01] Branch from build environment: 
INFO [24-09-18 9:18:19:01] -< Begin: Normalizing git directory for branch '' >-
  INFO [24-09-18 9:18:19:04] One remote found (origin -> 'https://github.com/…/…').
  INFO [24-09-18 9:18:19:04] Skipping fetching, if GitVersion does not calculate your version as expected you might need to allow fetching or use dynamic repositories
  INFO [24-09-18 9:18:19:05] Creating local branch from remote tracking ….
  INFO [24-09-18 9:18:19:06] Creating local branch from remote tracking ….
  INFO [24-09-18 9:18:19:06] Creating local branch from remote tracking ….
  INFO [24-09-18 9:18:19:06] Creating local branch from remote tracking ….
  INFO [24-09-18 9:18:19:07] Creating local branch from remote tracking ….
  INFO [24-09-18 9:18:19:07] Creating local branch from remote tracking ….
  INFO [24-09-18 9:18:19:07] Creating local branch from remote tracking ….
  INFO [24-09-18 9:18:19:07] Creating local branch from remote tracking ….
  INFO [24-09-18 9:18:19:07] Creating local branch from remote tracking 'refs/remotes/origin/main'.
  INFO [24-09-18 9:18:19:08] HEAD is detached and points at commit 'bd0483d972605906d5cc1d748c84c90a485d29ad'.
  INFO [24-09-18 9:18:19:08] Local Refs:
refs/tags/1.0 (9da7674a873c8457632f59487e7e2093f2bec198)
refs/tags/1.0.1 (22c0373b037e81fe5c0d2e32758137967f6effef)
refs/tags/1.0.2 (7fe3f4e494dc217a48f75173fb98ff941ca71762)
refs/tags/1.0.3 (531ffd5f142e510459a98e87cab40394de905293)
refs/tags/1.1.0 (a4493a58e04d195afd5b245f4ed1542db10a2b20)
refs/tags/1.1.1 (1f83d282d89f21cd3cccc7e81691dbfa3b5f7e13)
refs/tags/1.1.2 (8f40a679d9a716e10fccfb740d5cf42b4a577309)
refs/tags/1.2.0 (b0d8de7b4935df7baf8775b90195ab27dc577269)
refs/tags/1.2.1 (6c64c08e9a3c6b85ecc8beeca8abcead8077535b)
refs/tags/1.2.10-alpha.1 (ef56c4267258da3d59fecf2dd8aa2cc6a241d211)
refs/tags/1.2.2 (ab0ebf2b533ad268012e43d86bee328b1b4208dc)
refs/tags/1.2.3 (7e29cebb5942ddce12f7ea4e91ddcdfbe3c95016)
refs/tags/1.2.4 (882b731c5ea03907cf96af24c360548d842d8693)
refs/tags/1.2.5 (8738e3fcfb4d115735959db29ad2785175d0b5fe)
refs/tags/1.2.6 (e4e7193a30009fc732be28228510ee5141783348)
refs/tags/1.2.7 (3e63d02b7f664a975a3708329daf3d61c7c7297d)
refs/tags/1.2.8 (9ecfde9650384ed8d75759bca095bf633dc74fe3)
refs/tags/1.2.9 (3196dc0456304004bfb17c7431f6d791524e81a9)
refs/tags/1.3.0 (b7c153855cf46d83271344b3879e5459d82c76d1)
refs/tags/1.3.1 (6c9d0e908f6a788fb6dd46aa218119e0244ebdb6)
refs/tags/1.3.2 (aeaa170909a8cf13ee351c7ebf62f3c02f017ec1)
refs/tags/1.4.0 (ec85de877dbd5af669c0b71b553869456c1bfc44)
refs/tags/1.4.1 (bd0483d972605906d5cc1d748c84c90a485d29ad)
  INFO [24-09-18 9:18:19:08] No local branch pointing at the commit 'bd0483d972605906d5cc1d748c84c90a485d29ad'. Fake branch needs to be created.
  INFO [24-09-18 9:18:19:09] Fetching remote refs to see if there is a pull request ref
INFO [24-09-18 9:18:19:27] -< End: Normalizing git directory for branch '' (Took: 255.42ms) >-
ERROR [24-09-18 9:18:19:39] An unexpected error occurred:
LibGit2Sharp.LibGit2SharpException: remote authentication required but no callback set
   at LibGit2Sharp.Core.Ensure.HandleError(Int32 result) in /_/LibGit2Sharp/Core/Ensure.cs:line 154
   at LibGit2Sharp.Core.Ensure.ZeroResult(Int32 result) in /_/LibGit2Sharp/Core/Ensure.cs:line 172
   at LibGit2Sharp.Core.Proxy.git_remote_connect(RemoteHandle remote, GitDirection direction, GitRemoteCallbacks& remoteCallbacks, GitProxyOptions& proxyOptions) in /_/LibGit2Sharp/Core/Proxy.cs:line 2172
   at LibGit2Sharp.Network.ListReferencesInternal(String url, CredentialsHandler credentialsProvider, ProxyOptions proxyOptions) in /_/LibGit2Sharp/Network.cs:line 213
   at LibGit2Sharp.Network.ListReferences(Remote remote) in /_/LibGit2Sharp/Network.cs:line 55
   at GitVersion.Git.GitRepository.GetPullRequestReference(AuthenticationInfo auth, Remote remote, String headTipSha) in /_/src/GitVersion.LibGit2Sharp/Git/GitRepository.extended.cs:line 91
   at GitVersion.Git.GitRepository.<>c__DisplayClass33_0.<CreateBranchForPullRequestBranch>b__0() in /_/src/GitVersion.LibGit2Sharp/Git/GitRepository.extended.cs:line 61
   at GitVersion.Git.RepositoryExtensions.RunSafe(Action operation) in /_/src/GitVersion.LibGit2Sharp/Git/RepositoryExtensions.cs:line 9
   at GitVersion.Git.GitRepository.CreateBranchForPullRequestBranch(AuthenticationInfo auth) in /_/src/GitVersion.LibGit2Sharp/Git/GitRepository.extended.cs:line 51
   at GitVersion.GitPreparer.<>c__DisplayClass19_0.<EnsureHeadIsAttachedToBranch>b__3() in /_/src/GitVersion.Core/Core/GitPreparer.cs:line 241
   at GitVersion.Helpers.RetryAction`1.<>c__DisplayClass1_0.<Execute>b__0() in /_/src/GitVersion.Core/Helpers/RetryAction.cs:line 11
   at Polly.Policy`1.<>c__DisplayClass11_0.<Execute>b__0(Context _, CancellationToken _)
   at Polly.Retry.RetryEngine.Implementation[TResult](Func`3 action, Context context, CancellationToken cancellationToken, ExceptionPredicates shouldRetryExceptionPredicates, ResultPredicates`1 shouldRetryResultPredicates, Action`4 onRetry, Int32 permittedRetryCount, IEnumerable`1 sleepDurationsEnumerable, Func`4 sleepDurationProvider)
   at Polly.Retry.RetryPolicy`1.Implementation(Func`3 action, Context context, CancellationToken cancellationToken)
   at Polly.Policy`1.Execute(Func`3 action, Context context, CancellationToken cancellationToken)
   at Polly.Policy`1.Execute(Func`1 action)
   at GitVersion.Helpers.RetryAction`2.Execute(Func`1 operation) in /_/src/GitVersion.Core/Helpers/RetryAction.cs:line 30
   at GitVersion.Helpers.RetryAction`1.Execute(Action operation) in /_/src/GitVersion.Core/Helpers/RetryAction.cs:line 9
   at GitVersion.GitPreparer.EnsureHeadIsAttachedToBranch(String currentBranchName, AuthenticationInfo authentication) in /_/src/GitVersion.Core/Core/GitPreparer.cs:line 241
   at GitVersion.GitPreparer.NormalizeGitDirectory(Boolean noFetch, String currentBranchName, Boolean isDynamicRepository) in /_/src/GitVersion.Core/Core/GitPreparer.cs:line 181
   at GitVersion.GitPreparer.NormalizeGitDirectory(String targetBranch, Boolean isDynamicRepository) in /_/src/GitVersion.Core/Core/GitPreparer.cs:line 131
   at GitVersion.GitPreparer.PrepareInternal(GitVersionOptions gitVersionOptions) in /_/src/GitVersion.Core/Core/GitPreparer.cs:line 66
   at GitVersion.GitPreparer.Prepare() in /_/src/GitVersion.Core/Core/GitPreparer.cs:line 45
   at GitVersion.GitVersionCalculateTool.CalculateVersionVariables() in /_/src/GitVersion.Core/Core/GitVersionCalculateTool.cs:line 35
   at GitVersion.GitVersionExecutor.RunGitVersionTool(GitVersionOptions gitVersionOptions) in /_/src/GitVersion.App/GitVersionExecutor.cs:line 66
INFO [24-09-18 9:18:19:39] Please run `git log --graph --format="%h %cr %d" --decorate --date=relative --all --remotes=*` to see the git graph. This can help you troubleshoot any issues.

INFO [24-09-18 9:18:18:85] Applicable build agent found: 'GitHubActions'.
INFO [24-09-18 9:18:18:90] Working directory: /home/runner/work/explore.ludenso.com/explore.ludenso.com
INFO [24-09-18 9:18:19:01] Project root is: /home/runner/work/explore.ludenso.com/explore.ludenso.com/
INFO [24-09-18 9:18:19:01] DotGit directory is: /home/runner/work/explore.ludenso.com/explore.ludenso.com/.git
INFO [24-09-18 9:18:19:01] Branch from build environment: 
INFO [24-09-18 9:18:19:01] -< Begin: Normalizing git directory for branch '' >-
  INFO [24-09-18 9:18:19:04] One remote found (origin -> 'https://github.com/Ludenso/explore.ludenso.com').
  INFO [24-09-18 9:18:19:04] Skipping fetching, if GitVersion does not calculate your version as expected you might need to allow fetching or use dynamic repositories
  INFO [24-09-18 9:18:19:05] Creating local branch from remote tracking 'refs/remotes/origin/108-move-additional-experience-uids-to-a-separate-json-file'.
  INFO [24-09-18 9:18:19:06] Creating local branch from remote tracking 'refs/remotes/origin/96-move-away-from-azure-static-web-apps'.
  INFO [24-09-18 9:18:19:06] Creating local branch from remote tracking 'refs/remotes/origin/98-wcag-22-aa-compliancy'.
  INFO [24-09-18 9:18:19:06] Creating local branch from remote tracking 'refs/remotes/origin/dependabot/github_actions/gittools/actions-3.0.0'.
  INFO [24-09-18 9:18:19:07] Creating local branch from remote tracking 'refs/remotes/origin/dependabot/npm_and_yarn/microsoft/applicationinsights-web-3.3.2'.
  INFO [24-09-18 9:18:19:07] Creating local branch from remote tracking 'refs/remotes/origin/dependabot/npm_and_yarn/npm_and_yarn-1482e54221'.
  INFO [24-09-18 9:18:19:07] Creating local branch from remote tracking 'refs/remotes/origin/dependabot/npm_and_yarn/three-0.168.0'.
  INFO [24-09-18 9:18:19:07] Creating local branch from remote tracking 'refs/remotes/origin/dependabot/npm_and_yarn/tweenjs/tween.js-25.0.0'.
  INFO [24-09-18 9:18:19:07] Creating local branch from remote tracking 'refs/remotes/origin/main'.
  INFO [24-09-18 9:18:19:08] HEAD is detached and points at commit 'bd0483d972605906d5cc1d748c84c90a485d29ad'.
  INFO [24-09-18 9:18:19:08] Local Refs:
refs/heads/108-move-additional-experience-uids-to-a-separate-json-file (90538e2a99266e6e522ee7d831b62f72823a44e5)
refs/heads/96-move-away-from-azure-static-web-apps (820ff19adbd55b75bc1708535002f2276481b1b4)
refs/heads/98-wcag-22-aa-compliancy (7fa7594848f82fae27a91e3e06d21727522df381)
refs/heads/dependabot/github_actions/gittools/actions-3.0.0 (adc806c2dde296c0767ac8f75a0f2d82c429a447)
refs/heads/dependabot/npm_and_yarn/microsoft/applicationinsights-web-3.3.2 (2b659954f812cb72e3336b6882a5f986aae2db13)
refs/heads/dependabot/npm_and_yarn/npm_and_yarn-1482e54221 (2f852568463e9a4446204695893939b8df3fddac)
refs/heads/dependabot/npm_and_yarn/three-0.168.0 (d527cbabfab2be329e8e8e257ce56dbbc33dad1f)
refs/heads/dependabot/npm_and_yarn/tweenjs/tween.js-25.0.0 (b8accd9a2e7e56226024b1ebce1b39c3197aec8b)
refs/heads/main (7a443162ac73655f5e0f57bcccf8224de58a05dc)
refs/remotes/origin/108-move-additional-experience-uids-to-a-separate-json-file (90538e2a99266e6e522ee7d831b62f72823a44e5)
refs/remotes/origin/96-move-away-from-azure-static-web-apps (820ff19adbd55b75bc1708535002f2276481b1b4)
refs/remotes/origin/98-wcag-22-aa-compliancy (7fa7594848f82fae27a91e3e06d21727522df381)
refs/remotes/origin/dependabot/github_actions/gittools/actions-3.0.0 (adc806c2dde296c0767ac8f75a0f2d82c429a447)
refs/remotes/origin/dependabot/npm_and_yarn/microsoft/applicationinsights-web-3.3.2 (2b659954f812cb72e3336b6882a5f986aae2db13)
refs/remotes/origin/dependabot/npm_and_yarn/npm_and_yarn-1482e54221 (2f852568463e9a4446204695893939b8df3fddac)
refs/remotes/origin/dependabot/npm_and_yarn/three-0.168.0 (d527cbabfab2be329e8e8e257ce56dbbc33dad1f)
refs/remotes/origin/dependabot/npm_and_yarn/tweenjs/tween.js-25.0.0 (b8accd9a2e7e56226024b1ebce1b39c3197aec8b)
refs/remotes/origin/main (7a443162ac73655f5e0f57bcccf8224de58a05dc)
refs/tags/1.0 (9da7674a873c8457632f59487e7e2093f2bec198)
refs/tags/1.0.1 (22c0373b037e81fe5c0d2e32758137967f6effef)
refs/tags/1.0.2 (7fe3f4e494dc217a48f75173fb98ff941ca71762)
refs/tags/1.0.3 (531ffd5f142e510459a98e87cab40394de905293)
refs/tags/1.1.0 (a4493a58e04d195afd5b245f4ed1542db10a2b20)
refs/tags/1.1.1 (1f83d282d89f21cd3cccc7e81691dbfa3b5f7e13)
refs/tags/1.1.2 (8f40a679d9a716e10fccfb740d5cf42b4a577309)
refs/tags/1.2.0 (b0d8de7b4935df7baf8775b90195ab27dc577269)
refs/tags/1.2.1 (6c64c08e9a3c6b85ecc8beeca8abcead8077535b)
refs/tags/1.2.10-alpha.1 (ef56c4267258da3d59fecf2dd8aa2cc6a241d211)
refs/tags/1.2.2 (ab0ebf2b533ad268012e43d86bee328b1b4208dc)
refs/tags/1.2.3 (7e29cebb5942ddce12f7ea4e91ddcdfbe3c95016)
refs/tags/1.2.4 (882b731c5ea03907cf96af24c360548d842d8693)
refs/tags/1.2.5 (8738e3fcfb4d115735959db29ad2785175d0b5fe)
refs/tags/1.2.6 (e4e7193a30009fc732be28228510ee5141783348)
refs/tags/1.2.7 (3e63d02b7f664a975a3708329daf3d61c7c7297d)
refs/tags/1.2.8 (9ecfde9650384ed8d75759bca095bf633dc74fe3)
refs/tags/1.2.9 (3196dc0456304004bfb17c7431f6d791524e81a9)
refs/tags/1.3.0 (b7c153855cf46d83271344b3879e5459d82c76d1)
refs/tags/1.3.1 (6c9d0e908f6a788fb6dd46aa218119e0244ebdb6)
refs/tags/1.3.2 (aeaa170909a8cf13ee351c7ebf62f3c02f017ec1)
refs/tags/1.4.0 (ec85de877dbd5af669c0b71b553869456c1bfc44)
refs/tags/1.4.1 (bd0483d972605906d5cc1d748c84c90a485d29ad)
  INFO [24-09-18 9:18:19:08] No local branch pointing at the commit 'bd0483d972605906d5cc1d748c84c90a485d29ad'. Fake branch needs to be created.
  INFO [24-09-18 9:18:19:09] Fetching remote refs to see if there is a pull request ref
INFO [24-09-18 9:18:19:27] -< End: Normalizing git directory for branch '' (Took: 255.42ms) >-
ERROR [24-09-18 9:18:19:39] An unexpected error occurred:
LibGit2Sharp.LibGit2SharpException: remote authentication required but no callback set
   at LibGit2Sharp.Core.Ensure.HandleError(Int32 result) in /_/LibGit2Sharp/Core/Ensure.cs:line 154
   at LibGit2Sharp.Core.Ensure.ZeroResult(Int32 result) in /_/LibGit2Sharp/Core/Ensure.cs:line 172
   at LibGit2Sharp.Core.Proxy.git_remote_connect(RemoteHandle remote, GitDirection direction, GitRemoteCallbacks& remoteCallbacks, GitProxyOptions& proxyOptions) in /_/LibGit2Sharp/Core/Proxy.cs:line 2172
   at LibGit2Sharp.Network.ListReferencesInternal(String url, CredentialsHandler credentialsProvider, ProxyOptions proxyOptions) in /_/LibGit2Sharp/Network.cs:line 213
   at LibGit2Sharp.Network.ListReferences(Remote remote) in /_/LibGit2Sharp/Network.cs:line 55
   at GitVersion.Git.GitRepository.GetPullRequestReference(AuthenticationInfo auth, Remote remote, String headTipSha) in /_/src/GitVersion.LibGit2Sharp/Git/GitRepository.extended.cs:line 91
   at GitVersion.Git.GitRepository.<>c__DisplayClass33_0.<CreateBranchForPullRequestBranch>b__0() in /_/src/GitVersion.LibGit2Sharp/Git/GitRepository.extended.cs:line 61
   at GitVersion.Git.RepositoryExtensions.RunSafe(Action operation) in /_/src/GitVersion.LibGit2Sharp/Git/RepositoryExtensions.cs:line 9
   at GitVersion.Git.GitRepository.CreateBranchForPullRequestBranch(AuthenticationInfo auth) in /_/src/GitVersion.LibGit2Sharp/Git/GitRepository.extended.cs:line 51
   at GitVersion.GitPreparer.<>c__DisplayClass19_0.<EnsureHeadIsAttachedToBranch>b__3() in /_/src/GitVersion.Core/Core/GitPreparer.cs:line 241
   at GitVersion.Helpers.RetryAction`1.<>c__DisplayClass1_0.<Execute>b__0() in /_/src/GitVersion.Core/Helpers/RetryAction.cs:line 11
   at Polly.Policy`1.<>c__DisplayClass11_0.<Execute>b__0(Context _, CancellationToken _)
   at Polly.Retry.RetryEngine.Implementation[TResult](Func`3 action, Context context, CancellationToken cancellationToken, ExceptionPredicates shouldRetryExceptionPredicates, ResultPredicates`1 shouldRetryResultPredicates, Action`4 onRetry, Int32 permittedRetryCount, IEnumerable`1 sleepDurationsEnumerable, Func`4 sleepDurationProvider)
   at Polly.Retry.RetryPolicy`1.Implementation(Func`3 action, Context context, CancellationToken cancellationToken)
   at Polly.Policy`1.Execute(Func`3 action, Context context, CancellationToken cancellationToken)
   at Polly.Policy`1.Execute(Func`1 action)
   at GitVersion.Helpers.RetryAction`2.Execute(Func`1 operation) in /_/src/GitVersion.Core/Helpers/RetryAction.cs:line 30
   at GitVersion.Helpers.RetryAction`1.Execute(Action operation) in /_/src/GitVersion.Core/Helpers/RetryAction.cs:line 9
   at GitVersion.GitPreparer.EnsureHeadIsAttachedToBranch(String currentBranchName, AuthenticationInfo authentication) in /_/src/GitVersion.Core/Core/GitPreparer.cs:line 241
   at GitVersion.GitPreparer.NormalizeGitDirectory(Boolean noFetch, String currentBranchName, Boolean isDynamicRepository) in /_/src/GitVersion.Core/Core/GitPreparer.cs:line 181
   at GitVersion.GitPreparer.NormalizeGitDirectory(String targetBranch, Boolean isDynamicRepository) in /_/src/GitVersion.Core/Core/GitPreparer.cs:line 131
   at GitVersion.GitPreparer.PrepareInternal(GitVersionOptions gitVersionOptions) in /_/src/GitVersion.Core/Core/GitPreparer.cs:line 66
   at GitVersion.GitPreparer.Prepare() in /_/src/GitVersion.Core/Core/GitPreparer.cs:line 45
   at GitVersion.GitVersionCalculateTool.CalculateVersionVariables() in /_/src/GitVersion.Core/Core/GitVersionCalculateTool.cs:line 35
   at GitVersion.GitVersionExecutor.RunGitVersionTool(GitVersionOptions gitVersionOptions) in /_/src/GitVersion.App/GitVersionExecutor.cs:line 66

To fix all of these bugs and crashes, I believe we need to do as I write in https://github.com/GitTools/GitVersion/discussions/4183#discussioncomment-10484112:

I think what GitVersion needs to do is a ref-check of the checked out commit SHA, and if a tag is found matching the branch name, follow the logic as if it was a tagged commit on the main branch.

In a Unix terminal, the question "what is the highest tag currently pointing at the current commit" can be answered by the following command:

git tag --points-at "${sha}" | sort -n | tail -1

Something similar should be possible to do with libgit2sharp, I presume.

What is expected?

GitVersion should run on a checked out tag without problems and calculate a version as if it was a tagged commit on main.

Steps to Reproduce

I assumed a GitHub Actions workflow like this would be able to reproduce the issue consistently, but it unfortunately doesn't:

name: Deploy

on:
  workflow_dispatch:

jobs:
  gitversion:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gittools/actions/gitversion/[email protected]
        with:
          versionSpec: '6.x'
      - uses: gittools/actions/gitversion/[email protected]

I've tried to reproduce the problem in this workflow run, but for some reason, it doesn't fail. The main difference is the following log line:

INFO [24-09-18 9:18:19:08] No local branch pointing at the commit 'bd0483d972605906d5cc1d748c84c90a485d29ad'. Fake branch needs to be created.

GitVersion then goes on to attempt git fetch of the remote, which fails because GitVersion isn't authenticated. As GitVersion already should know that tag 1.4.1 points to the commit bd0483d972605906d5cc1d748c84c90a485d29ad (as can be seen by the log), it should just use 1.4.1 as the version number and not attempt any further normalization, Git fetch, or similar.

RepositoryFixture Test

No response

Output log or link to your CI build (if appropriate).

No response

[arihannu]

I'm facing this issue atm. In Bitbucket, I can select any commit, then run a pipeline that checks out that commit, however I am getting this same exception. Is there any workaround? I need to be able to rebuild older versions too. I have tried to create a new branch that includes only those commits that the older version had before, then I don't face this issue (there's then another problem with tags, version is taken from the latest tag from main branch, not the latest tag that is in my branch)..

[arturcic]

In a Unix terminal, the question "what is the highest tag currently pointing at the current commit" can be answered by the following command: git tag --points-at "${sha}" | sort -n | tail -1

What if you have 2 tags on the same commit, which one should you pick? What if the picked tag is not the one you want?

[asbjornu]

In Bitbucket, I can select any commit, then run a pipeline that checks out that commit, however I am getting this same exception.

@arihannu, for a random commit without any associated tags, I'm not sure what GitVersion should do. It at least needs to know which branch the build commit should be treated as. Should GitVersion just assume that a detached HEAD with no version tags pointing to it is to be treated as a commit on main? Or does detached HEAD need to be configurable with its own branch configuration? Thoughts @HHobeck?

What if you have 2 tags on the same commit, which one should you pick? What if the picked tag is not the one you want?

Elsewhere in GitVersion, we pick the highest version number available. Wouldn't that make sense in this case as well, @arturcic?

[arturcic]

I suspect that should be done in TaggedCommit strategy then

[HHobeck]

@arihannu, for a random commit without any associated tags, I'm not sure what GitVersion should do. It at least needs to know which branch the build commit should be treated as. Should GitVersion just assume that a detached HEAD with no version tags pointing to it is to be treated as a commit on main? Or does detached HEAD need to be configurable with its own branch configuration? Thoughts @HHobeck?

The business logic is as follows:

and

What if you have two tags on the same commit, which one should you pick? What if the picked tag is not the one you want?

If you have two tags it depends on the one hand on the effective branch configuration and on the other hand what kind of release tags you have.

Following scenarios coming to my mind for the GitFlow/v1 workflow with mode: ContinuousDelivery:

1. Tag 1.0.0 and 2.0.0 on main -> yields to 2.0.0
2. Tag 1.0.0 and 2.0.0-1 on main -> yields to 2.0.0-1
3. Tag 1.0.0 and 2.0.0-alpha.1 on main -> yields to 1.0.0
4. Tag 1.0.0 and 2.0.0-beta.1 on main -> yields to 1.0.0
5. Tag 1.0.0 and 1.0.1-beta.1 on main -> yields to 1.0.0
6. Tag 1.0.0 and 2.0.0 on develop -> yields to 2.1.0-alpha.0
7. Tag 1.0.0 and 2.0.0-1 on develop-> yields to 2.0.0-alpha.0
8. Tag 1.0.0 and 2.0.0-alpha.1 on develop -> yields to 2.0.0-alpha.2
9. Tag 1.0.0 and 2.0.0-beta.1 on develop -> yields to 2.0.0-alpha.0
10. Tag 1.0.0 and 1.0.1-beta.1 on develop -> yields to 1.1.0-alpha.0

Please keep in mind that:

• on main the label is empty and the prevent-increment_when-current-commit-tagged is set to true
• on develop the label is alpha and the prevent-increment_when-current-commit-tagged is set to false

Elsewhere in GitVersion, we pick the highest version number available. Wouldn't that make sense in this case as well, @arturcic? In any case it is important to define somehow what the current branch is.

The documentation says:

Detached HEAD

If HEAD is in detached state tag will be -no-branch-.

Example: 0.0.1--no-branch-.1+4

I have no idea for what this is good for. In my opinion an exception would be better if the current branch is not known.

[HHobeck]

I think we need to clarify what use cases we have when running gitversion by selecting just a tag commit and what the expected behavior might be.

In the log output from the current ticket it seems to me that you have selected a tag commit which is not part of any branch:

INFO [24-09-18 9:18:19:08] HEAD is detached and points at commit 'bd0483d972605906d5cc1d748c84c90a485d29ad'. .. refs/tags/1.4.1 (bd0483d972605906d5cc1d748c84c90a485d29ad) INFO [24-09-18 9:18:19:08] No local branch pointing at the commit 'bd0483d972605906d5cc1d748c84c90a485d29ad'. Fake branch needs to be created. INFO [24-09-18 9:18:19:09] Fetching remote refs to see if there is a pull request ref

Why would you create a tag on a branch and deleting the branch afterwards without merging the commit. Makes no sense in my opinion.

[HHobeck]

Why would you create a tag on a branch and deleting the branch afterwards without merging the commit. Makes no sense in my opinion.

On the other hand it might be generally a use case to produce the version number of the tag independent of the branch. Please see following discussion:

https://github.com/GitTools/GitVersion/discussions/4291#discussioncomment-11236502

The author @devorient want to help. Maybe we could agree on a concept.

[HHobeck]

The author @devorient want to help. Maybe we could agree on a concept.

@asbjornu: Can you help with the concept?

[asbjornu]

@HHobeck, I think the following question must be answered before we can proceed:

Should GitVersion just assume that a detached HEAD with no version tags pointing to it is to be treated as a commit on main?

I highly doubt everyone wants the same behavior for detached HEAD commits, so my gut feeling is that the answer to the above question is "no." We thus need to provide configuration for detached HEAD commits so that the default behavior can be overridden. But perhaps a full-fledged branch configuration isn't required, and something like the following would suffice?

treat-detached-head-as: main

This means detached HEAD commits will be versioned as if the commit was built on the main branch.

[HHobeck]

I highly doubt everyone wants the same behavior for detached HEAD commits, so my gut feeling is that the answer to the above question is "no." We thus need to provide configuration for detached HEAD commits so that the default behavior can be overridden. But perhaps a full-fledged branch configuration isn't required, and something like the following would suffice?

I'm not sure if it's good to introduce such a static value. To me, it doesn't make sense if e.g. you have a commit on a feature branch that was checked out in a detached state and is treated as if it were in the main branch (even I have reasonable doubts that the algorithm can calculate the versions in a meaningfull way).

I think we need to have a discussion based on following scenarios:

The user has:

1. checked out the repository locally in a detached head state
2. triggered the pipeline and the repository is checked out remotely in a detached head state (from tag or from commit)

Where the commit is based:

1. in no branch
2. in exactly one branch
3. in two or more branches

And the commit:

1. is not tagged
2. has one or more tags

In my opinion we have twelve scenarios with maybe different outcomes!!

[asbjornu]

@HHobeck, thank you for outlining the different scenarios. Indeed, a simple property won't cover all of these scenarios. But I think as a default, it might work if we also allow for runtime overrides. GitVersion already supports (although not fully) the Git_Branch environment variable. When set, it could force GitVersion to treat a detached HEAD commit as though it was made in the specified branch, with its associated branch configuration. Wouldn't that cover most scenarios?

[HHobeck]

I like the idea to use the environment variable Git_Branch locally as well to give gitversion a hint about the branch to use. But I would say the following constraint should be ensured:

• the commit needs to be part of the branch otherwise an exception is thrown

What do you think?

[devorient]

I like the idea of using Git_Branch for this, this also allows for external logic to be applied to cover corner cases. If the variable is missing, would you use a default branch like main or allow for configuration like:

treat-detached-head-as: main

[HHobeck]

Actually we have already an argument to set the target branch locally:

gitversion -b master -nocache

I have tested it and it works quite well. Please notice that the git preparer uses the agent specific target branch and as a fallback the target branch provided by arguments:

https://github.com/GitTools/GitVersion/blob/c63c1a30d0e77be2d7d9fde7aa6c0e6b91275c24/src/GitVersion.Core/Core/GitPreparer.cs#L78

[HHobeck]

I'm at a point where I'm not sure what we are discussing here. In my opinion GitVersion works well with detached head scenarios. All related issues are probably issues in the normalization process. That means we need just to ensure that the outcome is the same for each build agents.

GitVersion then goes on to attempt git fetch of the remote, which fails because GitVersion isn't authenticated. As GitVersion already should know that tag 1.4.1 points to the commit bd0483d972605906d5cc1d748c84c90a485d29ad (as can be seen by the log), it should just use 1.4.1 as the version number and not attempt any further normalization, Git fetch, or similar.

In my opinion the assumption that GitVersion needs to just use the tag without doing a normalization is wrong.

First example: Let's say you have a tag v0.2.0 as following:

* 783d08a8 (HEAD -> release/next, tag: v0.2.0, main, develop)

running GitVersion with GitFlow/v1 workflow on 783d08a8 produces:

• on main -> 0.2.0 (gitversion -b main)
• on develop -> 0.2.1-alpha.0 (gitversion -b develop)
• on release/next -> 0.2.1-beta.0 (gitversion -b release/next)

Second example: Let's say you have a tag v0.2.0 on a commit which is not part of any branch (because it was reverted):

* 123d456a7 (HEAD -> tag: v0.2.0)
* 783d08a8 (release/next, tag: v0.1.0, main, develop)

running GitVersion with GitFlow/v1 workflow on 123d456a7 will be the same like for 783d08a8:

• on main -> 0.1.0 (gitversion -b main)
• on develop -> 0.1.1-alpha.0 (gitversion -b develop)
• on release/next -> 0.1.1-beta.0 (gitversion -b release/next)

Does this make sense?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs.

[github-actions[bot]]

This issue was closed because it has been stalled for 30 days with no activity. Thank you for your contributions

[asbjornu]

I agree that we've talked a bit about many things in this issue, but to circle back to its origin; the problem is that GitVersion crashes. I don't think GitVersion should crash under any circumstance, especially not circumstances caused by relatively normal operations such as doing a detached HEAD checkout as described above. I think this problem has short-term and long-term solutions:

1. The short-term solution might be to do something like #4400 for the GitVerison build agent.
2. The long-term solution might be to move the build agent code from the GitVersion repository to the actions repository and solve more of it there.
3. Another long-term solution might be to define "input variables" just like the "output variables" we already have, each of which can be overridden by the user to suit the specific circumstance. This would also solve use-cases like the one discussed in #4456. I've created #4503 to discuss this idea in isolation.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs.

[enrico-barbieri-engagelabs]

I think i have a corner case for this thread: today I fired in Azure DevOps a build pipeline (which uses gitversion.tool inside) checking out a previous tag done, at the time, on a commit on master. I was expecting, since i checked out the exact commit the tag refers to, GitVersion returning the tag itself as a semver (the tag is v1.1.0, so it's a proper semver value) but i got the exception discussed in this thread.

I'm not advocating for a fix, because the matter is far more complex then my case because if the checked out tag is not a valid semver, my expectation is GitVersion returning the latest possible semver AT THE TIME (which I'm not even sure it is possible). I just want to understand if my expectation is wrong. If the purpose of a tag is to identify a specific release, why GitVersion just does not return the tag itself even if the detached head is pointing a valid tag?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs.

[giuliov-unum]

I see the same crash happening on version 6.4.0 for GitHub Actions. The pipeline was manually triggered selecting a tag.