Ambiguous refname happens since v2.177.1, checkout creates refs named as commit IDs

[tompazourek]

We recently updated build agents from v2.174.1 to v2.177.1 and started experiencing these issues (some of our own Git-based steps crashing):

warning: refname '69fe0cebcdf901b7c2b72132ea6c4cb34cc10a7d' is ambiguous.
Git normally never creates a ref that ends with 40 hex characters
because it will be ignored when you just specify 40-hex. These refs
may be created by mistake. For example,

  git checkout -b $br $(git rev-parse ...)

where "$br" is somehow empty and a 40-hex ref is created. Please
examine these refs and maybe delete them. Turn this message off by
running "git config advice.objectNameWarning false"

It seems to be caused by the recent PR #3127, more specifically these lines: https://github.com/microsoft/azure-pipelines-agent/pull/3127/files#diff-70b59b31500cd4671193074b2e8c1fdaa2889faa3afa6b432e367fb3734aa2f1R851-R860 (@jeschu1, @mjroghelia)

Basically, what happens is the following:

• Now the agent creates a ref with the same name as the commit ID in origin, e.g. origin/69fe0cebcdf901b7c2b72132ea6c4cb34cc10a7d (this is a new breaking change and it didn't use to do this)
• We use GitVersion in our pipeline that checks out all the branches, and also checks out origin/69fe0cebcdf901b7c2b72132ea6c4cb34cc10a7d as 69fe0cebcdf901b7c2b72132ea6c4cb34cc10a7d
• Then 69fe0cebcdf901b7c2b72132ea6c4cb34cc10a7d is ambiguous (it's both a branch, and also a commit ID), and it crashes things :/

I think creating refs that have the same names as commit IDs is a very bad practice in Git. All 40-character hex strings should be commit IDs and not refs, Git warns about that itself... Can we please not do that? Or at least provide some setting so that it can be disabled? Any thoughts on this?

The only workaround I can think of right now is to add an extra step that undoes what the checkout step does and deletes the origin/69fe0cebcdf901b7c2b72132ea6c4cb34cc10a7d ref right after the agent creates it...

Note we're using Azure Repos (part of our Azure DevOps Services) for our repository hosting, and although the PR #3127 was intended for GitHub repositories, it broke in Azure Repos for us.

[mjroghelia]

@tompazourek You can disable the fetch by commit behavior as a workaround by setting an environment variable for the agent (VSTS_DISABLEFETCHBYCOMMIT) to "true", or in the specific pipeline or job by setting the VSTS.DisableFetchByCommit build variable to "true".

[tompazourek]

@mjroghelia Thanks, I'll have to try that. I cannot find any documentation for that variable. Is this documented anywhere?

Where should I set this variable if I use the YAML-based pipelines? Recently, I found out that lot of the built-in variables are read-only and cannot be set anymore. So I'm wondering what's the right way right now...

[mjroghelia]

@tompazourek To define it for a single YAML pipeline, you can set the variable at the top level of the YAML:

variables:
  'VSTS.DisableFetchByCommit': 'true'

That would apply to all the jobs in that pipeline, but that pipeline only. You can likewise define the variable on a single job by putting that "variables" section within a particular "job:" section.

[IlyaChistov]

@tompazourek I am currently investigating this issue, and i cant seem to reproduce it. On default .net pipeline everything works as expected, and adding a GitVersion step doesn't change that. Could you please provide more detailed description of your pipeline so i could continue my investigation. Thanks!

[tompazourek]

@IlyaChistov Can you reproduce the that the pipeline creates a new ref, and that ref is in form of a commit ID?

In the pipeline log for git checkout, I see this command:

git -c http.extraheader="AUTHORIZATION: bearer ***" fetch --force --tags --prune --progress --no-recurse-submodules origin +c6335957f4267d054c35a6943ffabc09a9b7baae:refs/remotes/origin/c6335957f4267d054c35a6943ffabc09a9b7baae

This command itself creates a ref that has the same format as a commit ID, and that is the problem. Refs should not use the 40-character hexadecimal strings format as that format is reserved for commit IDs.

It's ambiguous and wrong. In Git, all 40-character hexadecimal string should be commit IDs, and I think that the Azure Pipelines Agent creates an ambiguous mess here creating refs that are named exactly the same as the commit IDs.

---

EDIT:

If you want to try to reproduce the refname warning, I imagine GitVersion runs something like:

git fetch origin refs/c6335957f4267d054c35a6943ffabc09a9b7baae:refs/c6335957f4267d054c35a6943ffabc09a9b7baae

And then the ambiguous warning happens when calling something like this (normally, this would checkout a commit, but now it's ambiguous between commit and the ref):

git checkout c6335957f4267d054c35a6943ffabc09a9b7baae

I haven't tested this though, but I hope it helps with trying to reproduce this

[lisamariet]

I am also experiencing this same error when I in my pipeline have an Azure Inline Powershell script that looks up all changes from current build branch and compares to latest on master.

So first we calls Azure Devops API:
##[debug]GET .../_apis/build/latest/DEFINITIONID?api-version=6.0-preview.1&branchName=master
to find the latest SourceVersion. So the response.SourceVersion (ex: bb3e659a02a130210f4dc7571d03a3a6693f169b) is used in the next git command:
git diff HEAD $response.sourceVersion --name-only

(Note: I can run this command locally on latest master branch without any error. )

When we merge to Master or do a commit on master branch the first build will work and no error is shown.
But if we start a new master build after the first one, which has no new commits.. then we always gets the error:
##[error]warning: refname 'bb3e659a02a130210f4dc7571d03a3a6693f169b' is ambiguous.

Sidenote:
We also get the warning mentioned above but run the suggested git config advice.objectNameWarning false to turn that warning off.

Edit: "Actually I wonder if it only fails when doing manual build... and the automatic builds are fine"

[github-actions]

This issue has had no activity in 180 days. Please comment if it is not actually stale