Azure Pipelines：「Git fetch failed with exit code: 128」
チェックアウトのステップは、エージェントの上で git fetch を動かします。失敗すると1〜10秒待ってやり直し、3回とも失敗するとこの行で止まります（エージェントのソース）。128 は git が致命的なエラーのときに使う終了コードなので、この行は原因について何も言っていません。原因はその直前に git が出した行にあります。上へたどって最初の remote: か fatal: の行を見つけ、下の該当する節を見てください（このメッセージの Stack Overflow の質問は9万7千回以上見られています）。
失敗しているのがプルリクエストのビルド検証なら、プルリクエストはそれを待っています：JetBrains IDE のプラグイン Azure DevOps Pull Requests は、プルリクエストのブランチ ポリシーを状態つきで IDE に並べ、Pro ならチェックアウトが直ったあとに失敗したビルド ポリシーをもう一度動かせます。JetBrains Marketplace で入れる
どう見えるか
##[warning]Git fetch failed with exit code 128, back off 4.271 seconds before retry.が2回（秒数は毎回変わります）、そのあと##[error]Git fetch failed with exit code: 128。- 同じ
fatal:の行で3回続けて失敗しているなら、ネットワークの一瞬の不調ではありません。下の原因を直すまで、ジョブを再実行しても同じ結果です。 - 行が
Git checkout failed with exit code: 128なら、取得はできていて、その中にコミットがなかったということです。最後の節を見てください。
remote: TF401019 や repository not found：ビルド サービスがリポジトリを読めない
- ジョブのトークンはあなたのものではなく、ビルド用の ID のものです。
{プロジェクト名} Build Service ({組織名})、またはジョブのスコープがコレクション全体ならProject Collection Build Service ({組織名})です（ジョブのアクセス トークンについての Microsoft のページ）。この ID にリポジトリの Read が要ります。一番読まれている質問の採用された回答は、Project settings の Repositories で、リポジトリのセキュリティにビルド サービスを足しています。 - 別のプロジェクトのリポジトリなら、Limit job authorization scope to current project for non-release pipelines がジョブを自分のプロジェクトの中に閉じ込めます。Project settings の Pipelines、Settings でこれを切るか（ある回答）、入れたまま、プロジェクトのビルド ID に相手のプロジェクトの View project-level information と、そのリポジトリの Read を与えます（同じ Microsoft のページの例のとおり）。
- Protect access to repositories in YAML pipelines は、2020年5月より後に作られた組織とプロジェクトでは既定で入っていて、ジョブが読めるリポジトリを、そのジョブの
checkoutステップかusesの文が名指ししたものだけに絞ります。スクリプトの中のただの git で取りに行くリポジトリは名指しされていないので、そのリポジトリのcheckoutステップを足します。このメッセージについて詳しくは TF401019 へ。
fatal: Authentication failed や could not read Username
- git が送ったトークンが断られたか、送るトークンがなかったかです。チェックアウトのステップは自分の取得にだけジョブのトークンを付けます。スクリプトの中の2回目の
git fetchやgit cloneには、チェックアウトのステップにpersistCredentials: trueがあるか、スクリプトが$(System.AccessToken)をヘッダーで渡さない限り付きません（ある回答はgit -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" fetchを示しています）。 - どちらなのかと、何を変えるかは could not read Username と Authentication failed へ。
プルリクエストがもう有効でない、プルリクエストのビルド
- プルリクエストのビルドでは、エージェントはプルリクエスト自身の ref、
refs/pull/<id>/mergeを取りに行きます（浅い取得ならそのマージ コミット）。取得のコマンドはログに出ています。キューに入ったビルドがそこまで進む前に誰かがプルリクエストを完了すると、取りに行くものがもうありません（同じ質問への回答：作ってすぐに完了した開発者がいた）。 - そのビルドは放っておいてかまいません。起きないようにするには、ターゲット ブランチのビルド検証のポリシーを Required にします。ビルドが通るまでプルリクエストを完了できなくなります（ポリシーを迂回する権限を持つ人はそれでも完了できます）。
セルフホストのエージェント：git のグローバル設定に残った extraheader
- エージェントは取得の前に、リポジトリ自身の git の設定から
http.extraheaderを消します。エージェントを動かしているユーザーのグローバル設定にあるものは残り、取得のたびに送られます。期限切れのトークンも一緒にです。このときエージェントは、git の設定にまだ extraheader のキーがあると警告します。 - そのユーザーで
git config --global --listを見て、git config --global --unset-all http.extraheaderで消します（同じ質問への別の回答）。よくある出どころは、トークンつきでgit config --globalを実行したスクリプトです。
エージェントがサーバーに届かない
Could not resolve hostやFailed to connectのような行はネットワークです。Microsoft がホストするエージェントはインターネットの上で動くので、会社のネットワークからしか見えない Azure DevOps Server や Git のサーバーには届きません（ある回答）。そのネットワークの中にセルフホストのエージェントを置きます。- セルフホストのエージェントなら、エージェントのマシンで、エージェントのユーザーとして、リポジトリの URL に
git ls-remoteを打つと、パイプラインの外で同じエラーが見えます。エージェントは自分の設定にあるプロキシを git に渡すので（エージェントを構成するときの--proxyurl）、プロキシはそこに書きます。 SSL certificate problem: unable to get local issuer certificateは、会社の CA の証明書です：git がどの証明書ストアを信頼するかへ。- Other Git のサービス接続でほかのホストのリポジトリを取るなら、接続の URL はリポジトリのクローン用の URL でなければならず、プロジェクトの Web ページの URL では動きません（ある回答）。
浅い取得での Git checkout failed with exit code: 128
- Azure Repos と Bitbucket では、エージェントはビルドするコミットをハッシュで取りに行くので、浅い取得でもそのコミットは手元に来ます。Other Git の接続（と、古い git での GitHub）では、浅い取得はブランチの新しいコミットしか持ってきません。ビルドするコミットがそれより古いと、たとえばブランチが進んだあとに再実行した回では、チェックアウトが失敗し、エージェントは取得の深さにチェックアウトするコミットが入っていないかもしれないと警告します。
- 2022年9月より後に作られた新しいパイプラインでは、組織によって Shallow fetch が深さ1で入っています（チェックアウトのステップのリファレンス）。全部の履歴が要るなら
checkoutのステップにfetchDepth: 0を書くか、パイプラインの設定の Triggers、YAML、Get sources で Shallow fetch を切ります。
IntelliJ IDEA と Rider で Azure DevOps のプルリクエスト
Azure DevOps Pull Requests は、JetBrains IDE 2024.1 以降と Android Studio で動く Lesstep のプラグインです。git のリモートから組織・プロジェクト・リポジトリを読み、あなたのレビュー待ちのプルリクエストを IDE のツール ウィンドウに並べます。Azure DevOps Services でも Azure DevOps Server でも動きます。プルリクエストのブランチ ポリシーを状態つきで見せるので、通っていない必須のビルドがプルリクエストの隣に出ます。Pro なら、失敗したビルド ポリシーや期限の切れたビルド ポリシーをそこからもう一度動かせます。レビューの受信箱は無料、投票・コメント・完了・作成は Pro（30日の無料試用つき）。
Azure DevOps と Azure Pipelines は Microsoft Corporation の商標、IntelliJ IDEA と Rider は JetBrains s.r.o. の商標です。このページはそのいずれとも提携しておらず、承認も受けていません。
ほかに：TF401019：リポジトリがないか、読む権限がない · git に送るトークンがなかった · トークンが断られた · English