パイプラインの開始エラーのトラブルシューティング
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
パイプラインがキューに登録されていても開始されない場合は、次の項目を確認します。
- 並列ジョブの制限 - 利用できるエージェントがないか、無料の上限に到達しています
- Azure DevOps からファイアウォールの背後にある Azure Key Vault にアクセスできない
- コンカレンシーが十分ではない
- ジョブが承認を待機している可能性がある
- 使用可能なエージェントが全部使用中
- エージェントの機能と一致しない要求
- サービスの低下がないか、Azure DevOps の状態を確認する
注意
次のシナリオでは、並列ジョブは使用されません。
- リリース パイプラインまたは複数ステージの YAML パイプラインを使う場合、実行では、ステージにアクティブに配置されているときにだけ並列ジョブが使われます。 リリースが承認または手動介入を待機している間は、並列ジョブは使われません。
- サーバー ジョブを実行するとき、またはリリース パイプラインを使って配置グループに配置するときは、並列ジョブを使いません。
並列ジョブの制限 - 利用できるエージェントがないか、無料の上限に到達しています
現在他のパイプラインを実行している場合は、並列ジョブが残っていないか、無料の上限に達している可能性があります。
使用可能な並列ジョブがあるかを確認する
注意
Azure Pipelines で、新しい組織でのパブリック プロジェクトと特定のプライベート プロジェクトに対する Microsoft ホステッド並列ジョブの自動無料許可が一時的に無効になっています。 並列ジョブがない場合、パイプラインは次のエラーで失敗します: ##[error]No hosted parallelism has been purchased or granted. To request a free parallelism grant, please fill out the following form https://aka.ms/azpipelines-parallelism-request
。 次のセクションで説明するように、Microsoft ホステッド並列ジョブを調べて、並列ジョブがない場合は、並列ジョブの無料許可を要求できます。 組織に対する並列ジョブの無料許可を要求するには、要求を送信します。 許可要求への応答を 2 から 3 営業日待ってください。
制限を調べるには、[プロジェクトの設定]、[並列ジョブ] の順に移動します。
Microsoft ホステッド エージェントを使っている場合は、Azure DevOps プロジェクトがプライベート プロジェクト (既定) かパブリック プロジェクトかに応じて、プライベート プロジェクトまたはパブリック プロジェクトについての Microsoft ホステッドに対する並列ジョブの制限を調べます。
制限を確認した後、コンカレンシーを調べて、現在実行中のジョブの数と使用可能なジョブの数を確認します。
現在他のパイプラインを実行している場合は、並列ジョブが残っていないか、無料の上限に達している可能性があります。
Azure DevOps からファイアウォールの背後にある Azure Key Vault にアクセスできない
パイプラインから Azure Key Vault にアクセスできない場合は、ファイアウォールによって Azure DevOps Services エージェントの IP アドレスがブロックされている可能性があります。 週単位の JSON ファイルで公開されている IP アドレスを、許可リストに登録する必要があります。 詳しくは、Microsoft ホステッド エージェントのネットワークに関する記事をご覧ください。
コンカレンシーが十分ではない
自分が持っているコンカレンシーの量を調べるには:
制限を調べるには、[プロジェクトの設定]、[並列ジョブ] の順に移動します。
このページには、
https://dev.azure.com/{org}/_settings/buildqueue?_a=concurrentJobs
に移動するか、ログから [並列ジョブの管理] を選ぶことで、アクセスすることもできます。コンカレンシーを調べるプール (Microsoft ホステッド プールまたはセルフ ホステッド プール) を決めて、[進行中のジョブの表示] を選びます。
[現在、X/X のジョブが実行されています] というテキストが表示されます。 両方の値が同じ場合、現在実行中のジョブが完了するまで保留中のジョブは待機します。
[プロジェクトの設定] から [エージェント プール] を選ぶことで、キューに登録されているジョブを含むすべてのジョブを表示できます。
この例では、コンカレント ジョブの制限は 1 であり、1 つのジョブが実行中で、1 つはキューに登録されています。 この例のように、すべてのエージェントがジョブの実行中でビジー状態の場合、さらにジョブをキューに登録すると、次のメッセージが表示されます:
The agent request is not running because all potential agents are running other requests. Current position in queue: 1
。 この例のジョブはキュー内の次のジョブであるため、その位置は 1 になります。
ジョブが承認を待機している可能性がある
パイプラインは、承認を待っているため、次のステージに移動しない可能性があります。 詳細については、「承認とチェックを定義する」を参照してください。
使用可能なエージェントが全部使用中
すべてのエージェントが現在ビジー状態になっている場合、ジョブは待機している可能性があります。 エージェントを調べるには:
https://dev.azure.com/{org}/_settings/agentpools
に移動します調べるエージェント プールを選び (この例では FabrikamPool)、[エージェント] を選びます。
このページには、現在オンラインまたはオフラインで使用中のすべてのエージェントが表示されます。 このページからプールにエージェントを追加することもできます。
エージェントの機能と一致しない要求
パイプラインの要求がどのエージェントの機能でも満たされない場合、パイプラインは開始しません。 一部のエージェントのみが必要な機能を備えていて、現在他のパイプラインを実行している場合、それらのエージェントのいずれかが使用可能になるまでパイプラインは停止します。
エージェントとパイプラインに対して指定されている機能と要求を確認するには、「機能」を参照してください。
注意
通常、機能と要求はセルフホステッド エージェントでのみ使われます。 エージェントのシステム機能と一致しない要求がパイプラインにある場合、一致する機能を持つエージェントに明示的にラベルを付けていない限り、パイプラインはエージェントを取得しません。
TFS エージェントの接続に関する問題
- エージェント接続のテスト中に構成が失敗する (オンプレミスの TFS のみ)
- エージェントの通信が失われる
- TFS ジョブ エージェントが開始されない
- 通知 URL が正しく構成されない (1.x エージェント バージョン)
エージェント接続のテスト中に構成が失敗する (オンプレミスの TFS のみ)
Testing agent connection.
VS30063: You are not authorized to access http://<SERVER>:8080/tfs
エージェントの構成中に上記のエラーが発生する場合は、TFS のコンピューターにログオンします。 インターネット インフォメーション サービス (IIS) マネージャーを開始します。 [匿名認証] が有効になっていることを確認します。
エージェントの通信が失われる
この問題の特徴は次のエラー メッセージです。
The job has been abandoned because agent did not renew the lock. Ensure agent is running, not sleeping, and has not lost communication with the service.
このエラーは、エージェントとサーバーの通信が数分にわたって失われたことを示している可能性があります。 エージェント コンピューターでのネットワークまたはその他の中断を除外するには、次の点を確認します。
- 自動更新がオフになっていることを確認します。 更新プログラムでコンピューターが再起動されると、ビルドまたはリリースが上記のエラーで失敗します。 この種の中断を避けるには、制御された方法で更新プログラムを適用します。 エージェント コンピューターを再起動する前に、プール管理ページでエージェントを無効としてマークし、実行中のビルドが完了できるようにします。
- スリープ設定がオフになっていることを確認します。
- エージェントが仮想マシンで実行されている場合は、マシンの正常性に数分間重大な影響を与えるおそれがある、ライブ マイグレーションやその他の VM メンテナンス操作を行わないようにします。
- エージェントが仮想マシンで実行されている場合は、同じオペレーティング システムの更新の推奨事項とスリープ設定の推奨事項がホスト マシンに適用されます。 また、ホスト マシンに影響を与えるその他のメンテナンス操作。
- パフォーマンス モニターのログや他の正常性メトリックのログは、この種のエラーを、エージェント コンピューター上の制約されたリソース (ディスク、メモリ、ページ ファイル、プロセッサ、ネットワーク) の可用性に関連付けるのに役立ちます。
- エラーとネットワークの問題を関連付けるもう 1 つの方法は、サーバーに無期限に ping を実行し、タイムスタンプと共に出力をファイルにダンプすることです。 20 秒や 30 秒などの正常な間隔を使います。 Azure Pipelines を使っている場合は、インターネット ドメイン (bing.com など) に ping を実行します。 オンプレミスの TFS サーバーを使っている場合は、同じネットワーク上のサーバーに ping を実行します。
- コンピューターのネットワーク スループットが適切であることを確認します。 オンライン速度テストを実行して、スループットをチェックできます。
- プロキシを使っている場合は、エージェントがプロキシを使うように構成されていることを確認します。 エージェントの配置に関するトピックを参照してください。
TFS ジョブ エージェントが開始されない
この問題の特徴として、Web コンソールに "エージェントが要求されるまで待機中" というメッセージが表示されることがあります。 TFSJobAgent (表示名: Visual Studio Team Foundation Background Job Agent) Windows サービスが開始されていることを確認します。
通知 URL が正しく構成されない (1.x エージェント バージョン)
この問題の特徴として、Web コンソールに "エージェントからのコンソール出力を待機しています" というメッセージが表示されることがあり、プロセスは最終的にタイムアウトします。
通知 URL が一致しない場合、ワーカー プロセスがサーバーに接続できない可能性があります。 "Team Foundation 管理コンソール" の "アプリケーション層" を確認してください。 1.x エージェントは、構成された URL を使ってメッセージ キューをリッスンします。 ただし、ジョブ メッセージがキューからプルされると、ワーカー プロセスは通知 URL を使ってサーバーに通信します。
サービスの低下がないか、Azure DevOps の状態を確認する
エージェントのキュー時間の増加など、サービス低下の原因になる可能性がある問題については、Azure DevOps サービス状態ポータルを確認してください。 詳しくは、「Azure DevOps Services の状態」をご覧ください。
さらにサポートが必要です。 バグを見つけました。 提案があります。 どこに行けばよいですか?
問題の報告またはフィードバックの送信は、Developer Community で行ってください。
皆様のご提案をお待ちしています。