Azure Pipelines: "Git fetch failed with exit code: 128"
The checkout step runs git fetch on the agent. When it fails, the agent waits 1 to 10 seconds and tries again, three tries in all, and then stops with this line (from the agent's source). 128 is the exit code git uses for any fatal error, so the line says nothing about the cause. The cause is in what git printed just before it: scroll up to the first remote: or fatal: line, and find it below (a Stack Overflow question on this message has been seen over 97,000 times).
When the failing build is a pull request's build validation, the pull request waits on it: Azure DevOps Pull Requests, a plugin for JetBrains IDEs, lists the pull request's branch policies with their state in your IDE, and with Pro runs a failed build policy again once checkout works. Get it on JetBrains Marketplace
What it looks like
##[warning]Git fetch failed with exit code 128, back off 4.271 seconds before retry.twice (the seconds change), then##[error]Git fetch failed with exit code: 128.- Three failures in a row with the same
fatal:line are not a network blip. Re-running the job gives the same result until the cause below is fixed. - If the line says
Git checkout failed with exit code: 128instead, the fetch worked and the commit was not in it. See the last section.
remote: TF401019, or repository not found: the build service may not read it
- The job's token belongs to a build identity, not to you:
{Project} Build Service ({Organization}), orProject Collection Build Service ({Organization})when the job scope is the whole collection (Microsoft's page on job access tokens). That identity needs Read on the repository. The accepted answer on the most read question added the build service under the repository's security in Project settings, Repositories. - For a repository in another project, Limit job authorization scope to current project for non-release pipelines keeps the job inside its own project. Either turn it off in Project settings, Pipelines, Settings (an answer), or keep it on and give the project's build identity View project-level information in the other project and Read on that repository, as in Microsoft's example on the same page.
- Protect access to repositories in YAML pipelines, on by default for organizations and projects created after May 2020, limits a job to the repositories that a
checkoutstep or ausesstatement in that job names. A repository fetched with plain git in a script is not named, so add acheckoutstep for it. More on this message: TF401019.
fatal: Authentication failed, or could not read Username
- git sent a token that was refused, or had none to send. The checkout step adds the job's token to its own fetch; a second
git fetchorgit clonein a script does not get it unless the checkout step hadpersistCredentials: true, or the script passes$(System.AccessToken)in a header (an answer showsgit -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" fetch). - Which one, and what to change: could not read Username and Authentication failed.
A pull request build whose pull request is no longer active
- For a pull request build, the agent fetches the pull request's own ref,
refs/pull/<id>/merge, or its merge commit when the fetch is shallow; the fetch command is printed in the log. If someone completes the pull request before the queued build gets that far, there is nothing left to fetch (an answer on the same question: a developer completed it right after creating it). - That build can be ignored. To stop it happening, make the build validation policy Required on the target branch, so a pull request cannot be completed until its build has passed (people with the permission to bypass policies still can).
A self-hosted agent: an extraheader left in git's global config
- Before fetching, the agent removes any
http.extraheadersetting from the repository's own git config. One in the global config of the user the agent runs as stays, and is sent with every fetch, an expired token with it. The agent then warns that git config still contains extraheader keys. - Look with
git config --global --listas that user, and remove it withgit config --global --unset-all http.extraheader(another answer on the same question). The usual source is a script that rangit config --globalwith a token.
The agent cannot reach the server
- Lines such as
Could not resolve hostorFailed to connectare the network. A Microsoft-hosted agent runs on the internet, so it cannot reach an Azure DevOps Server or Git server that only your company network can see (an answer); use a self-hosted agent inside that network. - On a self-hosted agent, run
git ls-remotewith the repository's URL from the agent machine, as the agent's user, to see the same error outside the pipeline. The agent hands git the proxy from its own configuration (the--proxyurloption when you configure the agent), so set it there. SSL certificate problem: unable to get local issuer certificateis a certificate from your company's CA: which store git trusts.- For a repository on another host through an Other Git service connection, the URL in the connection must be the repository's clone URL, not the web page of the project (an answer).
Git checkout failed with exit code: 128 on a shallow fetch
- For Azure Repos and Bitbucket the agent fetches the commit to build by its hash, so a shallow fetch still has it. With an Other Git connection (and GitHub with an old git), a shallow fetch brings only the newest commits of the branch. When the commit to build is older, for example in a retried run after the branch moved on, checkout fails, and the agent warns that the fetch depth may not include the checkout commit.
- In some organizations, new pipelines created after September 2022 have Shallow fetch on with a depth of 1 (the checkout step's reference). Set
fetchDepth: 0on thecheckoutstep for full history, or turn Shallow fetch off in the pipeline's settings under Triggers, YAML, Get sources.
Azure DevOps pull requests in IntelliJ IDEA and Rider
Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later and Android Studio, reads the organization, project and repository from your git remote and lists the pull requests that wait for your review in an IDE tool window, on Azure DevOps Services and on Azure DevOps Server. It shows the branch policies of a pull request with their state, so a required build that has not passed is next to its pull request, and with Pro you run a failed or expired build policy again from there. The review inbox is free; voting, commenting, completing and creating are Pro, with a 30-day trial.
Get it on JetBrains Marketplace
Azure DevOps and Azure Pipelines are trademarks of Microsoft Corporation; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft or JetBrains.
More: TF401019: the repository does not exist or you may not read it · git had no token to send · the token was refused · 日本語