azure-pipelines-agent: Git lfs exit code 2 - on second git lfs fetch

Have you tried trouble shooting?

Yes, in fact I found another bug that when you set GIT_TRACE globally the agent will crash.

Agent Version and Platform

Version of your agent: 2.131.0 Version of git: 2.16.1.windows.4 Version of git-lfs: git-lfs/2.3.0 (GitHub; windows amd64; go 1.8.3; git 4dd2bf73

Running on Windows 7

VSTS Type and Version

On-Prem TFS 2017.3 (15.117.27414.0)?

What’s not working?

Basically the problem is the following:

• We have a git project with lfs files
• We have a build
• After clearing the source directory (ie .git folder in the agent for the build) the build always works fine
• The build works fine for the same git-“branch”
• When running the build for a different git-branch we get the following output (domain and project name changed):

Fetch LFS objects for git repository at: C:\TFS\work\2\s remote: origin.

git -c http.http://tfs.<domain>:8080.extraheader="AUTHORIZATION: bearer ***" lfs fetch origin <sha1>
Fetching <sha1>

batch response: Git credentials for http://tfs.<domain>:8080/tfs/<teamproject>/_git/<project> not found.
batch response: Git credentials for http://tfs.<domain>:8080/tfs/<teamproject>/_git/<project> not found.
Git LFS: (0 of 128 files) 0 B / 888.38 MB                                      
error: failed to fetch some objects from 'http://tfs.<domain>:8080/tfs/<teamproject>/_git/<project>.git/info/lfs'

Get git-lfs logs.

git lfs logs last
No logs to show

Git lfs fetch failed with exit code: 2. Git lfs logs returned with exit code: 0.

System.InvalidOperationException: Git lfs fetch failed with exit code: 2. Git lfs logs returned with exit code: 0.

The log is already the most verbose setting I could figure out (and I even tried to compile the agent myself and “hack-in” GIT_TRACE support).

Agent and Worker’s Diagnostic Logs

See above

Related Repositories

I guess this is the correct place.

Questions:

• Any idea how to further diagnose this?
• Running locally on the agent works (ie git is asking for password) so I’d assume it is related to the “token”
• I’d assume it has to do with how we have different lfs files across the branches (ie. the same file might be a lfs file in one branch and checked-in directly in another one or not exist at all)