Azure DevOps：Azure Artifacts のフィードで「Unable to load the service index for source」
NuGet は何かをダウンロードする前に、フィードのサービス インデックス、つまり nuget.config にある index.json のアドレスを読みます。Azure Artifacts がその要求を断ると、restore はここで止まります。後ろに続くステータス コードで向きがわかります。401 は資格情報が送られなかったか、受け付けられなかったということ。403 は誰なのかはわかったが、その ID がフィードのロールを持っていないということです（このメッセージの Stack Overflow の質問は14万回以上見られ、これを含む Azure DevOps の質問は合わせて70万回以上見られています）。
プルリクエストのビルド検証で restore が失敗しているなら、プルリクエストはそれを待っています：JetBrains IDE のプラグイン Azure DevOps Pull Requests は、プルリクエストのブランチ ポリシーを状態つきで IDE に並べ、Pro ならフィードがビルドを通すようになったあとに、失敗したビルド ポリシーをもう一度動かせます。JetBrains Marketplace で入れる
どう見えるか
error NU1301: Unable to load the service index for source https://pkgs.dev.azure.com/fabrikam/Web/_packaging/shared/nuget/v3/index.json.のあとに、Response status code does not indicate success: 401 (Unauthorized).か403 (Forbidden)。- .NET のタスクの restore コマンドからは、警告
For internal feeds, make sure the build service identity '...' [...] has access to the feed.とPackages failed to restoreも出ます。警告にはジョブが動いた ID の名前が入っていて、フィードの権限で探すのはその ID です。 - 本文に、ユーザーに権限がなく
ReadPackagesが要ると書かれた 403 は、ロールのないビルド ID です（これについての質問の採用された回答）。
パイプラインでは：ビルド ID にフィードのロールを与える
- ジョブは
{プロジェクト名} Build Service ({組織名})かProject Collection Build Service ({組織名})として動きます。Artifacts でフィードを開き、Feed settings、Permissions、Add users/groups から、その ID を足します（フィードの権限についての Microsoft のページ）。 - Feed Reader は、フィードにすでにあるものをダウンロードできます。Feed and Upstream Reader (Collaborator) は、それに加えて nuget.org のようなアップストリームからパッケージを保存できます。フィードがまだ持っていないパッケージをビルドが初めて求めたときに起きるのがこれです。Microsoft がビルド ID に既定で与えているのもこのロールで、restore にはこれを与えます。パッケージを push するなら、両方の ID に Feed Publisher (Contributor) を与えます。
dotnet build が、資格情報なしでもう一度 restore する
- .NET のタスクの restore コマンド（
DotNetCoreCLI@2のcommand: restore）は、フィードの資格情報を一時的なnuget.configに書き、それを使ってdotnet restoreを動かし、終わったら消します（タスクのソース）。dotnet build・test・publish・packは既定でもう一度 restore し、そのときはリポジトリのnuget.configを資格情報なしで使います。失敗しているのはこちらの restore です。 - それらのステップの
argumentsに--no-restoreを渡すか、その前に- task: NuGetAuthenticate@1を置きます。このタスクは Azure Artifacts Credential Provider を入れるので、ジョブのそれ以降の dotnet・nuget・MSBuild のコマンドは、組織の中のフィードの資格情報を受け取ります（タスクのリファレンス。一番読まれている質問で一番票を集めた回答もこれ）。dotnet tool restoreや、ただのscriptステップの中のdotnet restoreも、これで直ります。 - dotnet 6 以降が要ります。
NuGetAuthenticate@0から移したあとの 401 で、ログの前のほうにIt was not possible to find any compatible framework versionがあれば、エージェントに .NET 6 がありません。リファレンスのとおり、先にUseDotNet@2を足します。
restore のタスク自身のフィードの設定
feedsToUse: selectでは、vstsFeedに組織スコープのフィードは名前だけ、プロジェクト スコープのフィードはプロジェクト名/フィード名で書きます（タスクのヘルプ）。feedsToUse: configとnugetConfigPathでは、同じ組織の中のフィードは何もしなくてもビルドの資格情報を受け取ります。組織の外のフィードには、externalFeedCredentialsに NuGet のサービス接続を書きます。
フィードが別のプロジェクトや組織にある
- 同じ組織の別のプロジェクト：Limit job authorization scope to current project が入っていると、ジョブはパイプラインのプロジェクトの
{プロジェクト名} Build Serviceとして動くので、Project Collection Build Service だけでなく、その ID にもフィードのロールが要ります（採用された回答は、フィードの権限を足しても直らなかったあとでこの設定を見つけています）。Microsoft のフィードのページは、フィードのあるプロジェクトでその ID にプロジェクト レベルの権限も求めています。スコープの設定そのものは、チェックアウトのページの TF401019 の節にあります。 - 別の組織：ビルドのトークンはそこまで届きません。その組織で作った、パッケージを読める個人用アクセス トークンで NuGet のサービス接続を作り、
NuGetAuthenticate@1のnuGetServiceConnectionsか、restore のタスクのexternalFeedCredentialsに書きます。 - フォークからのプルリクエスト：外部のフォークから動いた実行は、内部のフィードの認証に使うシークレットを受け取りません。NuGetAuthenticate は成功したように見え、あとのステップが失敗します。タスクのリファレンスの例は VS800075 つきの 500 です。プルリクエストがマージされれば、そのマージで動いた実行は認証できます。
自分のマシンでは
- dotnet：Azure Artifacts Credential Provider を入れ（
dotnet tool install --global Microsoft.Artifacts.CredentialProvider.NuGet.Tool、.NET SDK 9.0.200 以降で）、dotnet restore --interactiveを一度動かします。サインインしてトークンを持つので、トークンの期限までは--interactiveなしで動きます（dotnet の設定についての Microsoft のページ）。 - パスワードを変えたあとの Visual Studio：古い資格情報を送り続けることがあります。資格情報マネージャーの Windows 資格情報で、
VSCredentials_<ドメイン>のような名前のものを消すと、Visual Studio がもう一度聞いてきます（ある回答）。 nuget.configのpackageSourceCredentialsに置いた個人用アクセス トークンは、期限が切れたときや、パッケージを読む権限がないときに 401 になります。新しく作り、リポジトリのではなく、ユーザーのnuget.configに置きます。
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 Artifacts・Azure Pipelines・NuGet・Visual Studio は Microsoft Corporation の商標、IntelliJ IDEA と Rider は JetBrains s.r.o. の商標です。このページはそのいずれとも提携しておらず、承認も受けていません。
ほかに：npm：同じフィードからの E401 Unable to authenticate · dotnet のタスクがプロジェクトを見つけられない · チェックアウトが Git fetch failed with exit code: 128 で止まる · デプロイのタスクが見る先に zip がない · English