パイプラインの実行をトラブルシューティングする

[アーティクル]
04/02/2024

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

パイプライン実行を完了できない場合は、パイプライン実行の概要ページで提供される診断情報とログを使用して、問題のトラブルシューティングに役立てることができます。

ログを表示する

エラーメッセージを選択して、完了できなかったタスクのログを表示します。

パイプライン実行の概要ページのタスクエラーメッセージのスクリーンショット。

ログページが表示され、選択したエラーが示されます。この例では、cmd-line タスクにエラーがあり、echo コマンドが ech として入力されています。

タスクの生ログは、[生ログの表示] を選択して表示でき、ログは、[検索] を使用して検索できます。

Azure DevOps のログビューオプションのスクリーンショット。

失敗したタスクのログをスキャンして、タスクが失敗した理由に関するエラー情報と手掛かりを確認します。既定では、非詳細ログがパイプライン実行によって生成されます。既定のログに問題の原因が示されていない場合は、詳細ログを構成することで詳細情報を取得できます。

[エラー分析] ページ

[エラー分析] ページを使用すると、トラブルシューティングに役立ちます。エラー情報行の上にマウスを移動し、[分析の表示] アイコンを選択します。

セルフホステッドエージェントの [エージェントの表示] (または Microsoft によってホストされるエージェントの場合は、[ホステッドエージェントイメージについて]) を選択して、パイプラインの実行に使用されるエージェントの詳細を表示し、[ログの表示] を選んでパイプライン実行ログを表示します。

Azure DevOps ポータルのエラー分析ページのスクリーンショット。

[実行時の詳細] の下にあるタスクの名前を選択して、タスクに関する情報を表示します。

エラー分析のタスクの詳細のスクリーンショット。

この例では、Script の Value にエラーがあることがわかります。タスクのドキュメントを表示するには、[このタスクについて] を選択します。

パイプライン実行の概要ページやログの参照では問題が明らかでない場合は、次の「一般的な問題」セクションを確認し、追加の診断情報を含むログ全体のダウンロードについては、「ログを確認してパイプラインの問題を診断する」を参照してください。

失敗したパイプライン実行に関するタスクの分析情報

Azure DevOps には、[失敗したパイプライン実行に関するタスクの分析情報] 設定が用意されています。これを有効にすると、ビルドエラーのポップアップ通知が、レポートを表示するためのリンクと一緒に表示されます。

タスク分析情報メトリックのスクリーンショット。

この設定を構成するには、[プレビュー機能] に移動し、[失敗したパイプライン実行に関するタスクの分析情報] を見つけて、必要な設定を選択します。

[失敗したパイプライン実行に関するタスクの分析情報] 設定のスクリーンショット。

ジョブのタイムアウト

パイプラインは長時間実行されてから、ジョブのタイムアウトが原因で失敗する可能性があります。ジョブのタイムアウトは、使用されているエージェントに大きく依存します。無料の Microsoft ホステッドエージェントの最大タイムアウトは、プライベートリポジトリの場合はジョブあたり 60 分、パブリックリポジトリの場合は 360 分です。ジョブの最大タイムアウトを増やすには、次のいずれかを選択できます。

使われているリポジトリに関係なく、すべてのジョブに 360 分を提供する、Microsoft ホステッドエージェントを購入します
セルフホステッドエージェントを使って、エージェントによるタイムアウトの問題を排除します

ジョブのタイムアウトに関する詳細を理解してください。

注意

Microsoft ホステッドエージェントジョブがタイムアウトする場合は、ジョブの最大タイムアウトより短いパイプラインタイムアウトを指定していないことを確認します。調べるには、「タイムアウト」をご覧ください。

コードのダウンロードに関する問題

パイプラインが checkout ステップで失敗する
Team Foundation バージョン管理 (TFVC) の問題

パイプラインが checkout ステップで失敗する

組織でパイプラインとは異なるプロジェクトにある Azure Repos Git リポジトリの checkout ステップを使っている場合は、[ジョブの承認スコープを現在のプロジェクトに制限する] の設定が無効になっていることを確かめるか、「スコープ付きビルド ID」の手順に従って、確実にパイプラインがリポジトリにアクセスできるようにします。

ジョブ承認スコープが制限されているためにパイプラインがリポジトリにアクセスできない場合は、Git fetch failed with exit code 128 というエラーが発生し、ログには次のようなエントリが含まれます: Remote: TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting.

パイプラインが Could not find a project that corresponds with the repository ですぐに失敗する場合は、checkout ステップまたはリポジトリリソースの宣言で、プロジェクトとリポジトリの名前が正しいことを確認します。

Team Foundation バージョン管理 (TFVC) の問題

ソースの取得で一部のファイルがダウンロードされない
Team Foundation プロキシを通したソースの取得

ソースの取得で一部のファイルがダウンロードされない

この問題の特徴として、ログに tf get コマンドからの "すべてのファイルは最新です" というメッセージが記録されることがあります。組み込みのサービス ID に、ソースをダウンロードするアクセス許可があることを確認してください。ビルドパイプラインの [全般] タブで選んだ承認スコープに応じて、"プロジェクトコレクションビルドサービス" または "プロジェクトビルドサービス" のどちらかの ID に、ソースをダウンロードするためのアクセス許可が必要です。バージョン管理 Web UI では、フォルダー階層の任意のレベルでプロジェクトファイルを参照し、セキュリティ設定をチェックできます。

Team Foundation プロキシを通したソースの取得

Team Foundation プロキシを通してソースを取得するようにエージェントを構成する最も簡単な方法は、エージェントの実行ユーザーとして TFVC プロキシサーバーを指す環境変数 TFSPROXY を設定することです。

Windows の場合:

    set TFSPROXY=http://tfvcproxy:8081
    setx TFSPROXY=http://tfvcproxy:8081 // If the agent service is running as NETWORKSERVICE or any service account you can't easily set user level environment variable

macOS/Linux の場合:

    export TFSPROXY=http://tfvcproxy:8081

MSBUILD などのコマンドラインステップでパイプラインが失敗する

ビルドまたはリリースの失敗が Azure Pipelines や TFS 製品の問題 (エージェントまたはタスク) の結果であるかどうかを絞り込むと役に立ちます。ビルドとリリースの失敗は、外部コマンドの結果である可能性もあります。

失敗したタスクによって実行された正確なコマンドラインのログを確認します。コマンドラインからコマンドをローカルで実行しようとすると、問題が再現する可能性があります。自分のコンピューターからコマンドをローカルで実行したり、コンピューターにサインインしてサービスアカウントとしてコマンドを実行したりすると、役に立つことがあります。

たとえば、ビルドパイプラインの MSBuild 部分で問題が発生しますか (たとえば、MSBuild または Visual Studio Build タスクを使っていますか)。そうである場合は、ローカルコンピューターで同じ引数を使って同じ MSBuild コマンドを実行してみてください。ローカルコンピューターで問題を再現できる場合は、次のステップとして、MSBuild の問題を調べます。

ファイルのレイアウト

ビルドに必要なツール、ライブラリ、ヘッダー、その他のもののホステッドエージェントでの場所は、ローカルコンピューターとは異なる場合があります。これらのファイルのいずれかが見つからないためにビルドが失敗する場合は、次のスクリプトを使ってエージェントでのレイアウトを調べることができます。これは、見つからないファイルを追跡するのに役立つ場合があります。

一時的な場所に新しい YAML パイプラインを作成します (トラブルシューティングのために作成された新しいリポジトリなど)。記述されているように、スクリプトはパス上のディレクトリを検索します。必要に応じて、SEARCH_PATH= 行を編集して他の場所を検索できます。

# Script for Linux and macOS
pool: { vmImage: ubuntu-latest } # or whatever pool you use
steps:
- checkout: none
- bash: |
    SEARCH_PATH=$PATH  # or any colon-delimited list of paths
    IFS=':' read -r -a PathDirs <<< "$SEARCH_PATH"
    echo "##[debug] Found directories"
    for element in "${PathDirs[@]}"; do
        echo "$element"
    done;
    echo;
    echo;  
    echo "##[debug] Found files"
    for element in "${PathDirs[@]}"; do
        find "$element" -type f
    done

# Script for Windows
pool: { vmImage: windows-2019 } # or whatever pool you use
steps:
- checkout: none
- powershell: |
    $SEARCH_PATH=$Env:Path
    Write-Host "##[debug] Found directories"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Write-Host "$Dir"
    }
    Write-Host ""
    Write-Host ""
    Write-Host "##[debug] Found files"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Get-ChildItem $Dir -File -ErrorAction Continue | ForEach-Object -Process {
        Write-Host $_.FullName
      }
    }

ローカルコマンドプロンプトとエージェントの違い

ローカルコンピューターでコマンドを実行するときと、ビルドまたはリリースがエージェントで実行されているときでは、いくつかの違いがあることに注意してください。エージェントが Linux、macOS、または Windows でサービスとして実行するように構成されている場合、対話型ログオンセッション内では実行されません。対話型のログオンセッションがない場合、UI の相互作用やその他の制限が存在します。

使用中のファイルまたはフォルダーのエラー

File or folder in use エラーは、多くの場合、次のようなエラーメッセージによって示されます。

Access to the path [...] is denied.
The process cannot access the file [...] because it is being used by another process.
Access is denied.
Can't move [...] to [...]

トラブルシューティングの手順:

使われているファイルとフォルダーを検出する
ウイルス対策の除外
MSBuild と /nodeReuse:false
MSBuild と /maxcpucount:[n]

使用中のファイルとフォルダーを検出する

Windows では、プロセスモニターなどのツールを使って、特定のディレクトリでのファイルイベントのトレースをキャプチャできます。または、タイムリーなスナップショットの場合は、Process Explorer や Handle などのツールを使用できます。

ウイルス対策の除外

ファイルをスキャンするウイルス対策ソフトウェアは、ビルドまたはリリースの間にファイルまたはフォルダーの使用中エラーの原因になる可能性があります。エージェントディレクトリと構成されている "作業フォルダー" に対するウイルス対策の除外を追加すると、ウイルス対策ソフトウェアが干渉しているプロセスであることを識別するのに役立つ場合があります。

MSBuild と /nodeReuse:false

ビルドの間に MSBuild を呼び出す場合は、必ず引数 /nodeReuse:false (短い形式 /nr:false) を渡します。そうしないと、ビルドの完了後も MSBuild プロセスが実行されたままになります。後続のビルドの可能性を見込んで、プロセスはしばらく残ります。

MSBuild のこの機能は、MSBuild プロセスの作業ディレクトリと競合するため、ディレクトリの削除または移動の試みと干渉する可能性があります。

MSBuild タスクと Visual Studio Build タスクでは、MSBuild に渡される引数に既に /nr:false が追加されています。ただし、独自のスクリプトから MSBuild を呼び出す場合は、引数を指定する必要があります。

MSBuild と /maxcpucount:[n]

既定では、MSBuild や Visual Studio Build などのビルドタスクは、/m スイッチを使って MSBuild を実行します。場合によっては、これにより、複数のプロセスファイルのアクセスの問題などの問題が発生する可能性があります。

/m:1 引数をビルドタスクに追加して、強制的に MSBuild が一度に 1 つのプロセスのみを実行するようにしてみます。

MSBuild のコンカレントプロセス機能をそのままにすると、ファイル使用中の問題が発生する可能性があります。引数 /maxcpucount:[n] (短い形式 /m:[n]) を指定しないと、MSBuild は 1 つのプロセスのみを使うように指示されます。 MSBuild または Visual Studio Build タスクを使っている場合は、既定で追加される "/m" 引数をオーバーライドするために "/m:1" を指定することが必要な場合があります。

断続的または一貫性のない MSBuild エラー

間欠的な、または一貫性のない MSBuild エラーが発生する場合は、1 つのプロセスのみを使うように MSBuild に指示してみます。間欠的な、または一貫性のないエラーは、ターゲットの構成が MSBuild のコンカレントプロセス機能と互換性を持たないことを示している可能性があります。「MSBuild と /maxcpucount:[n]」をご覧ください。

プロセスが応答を停止する

プロセスが応答を停止する原因と、トラブルシューティングの手順:

入力待ち
プロセスダンプ
WiX プロジェクト

入力待ち

応答しないプロセスは、プロセスが入力を待っていることを示している可能性があります。

対話型ログオンセッションのコマンドラインからエージェントを実行すると、プロセスがダイアログで入力を求めているかどうかを特定するのに役立つ場合があります。

エージェントをサービスとして実行すると、プログラムが入力を求めないようにするのに役立つことがあります。たとえば、.NET では、プログラムは System.Environment.UserInteractive ブール値に依存して、入力を求めるかどうかを判断する場合があります。エージェントが Windows サービスとして実行されている場合、値は false です。

プロセスダンプ

プロセスのダンプを分析すると、デッドロックしたプロセスが待機している内容を特定するのに役立ちます。

WiX プロジェクト

カスタム MSBuild ロガーが有効になっているときに WiX プロジェクトをビルドすると、WiX が出力ストリームを待機してデッドロックが発生する可能性があります。 MSBuild の引数 /p:RunWixToolsOutOfProc=true を追加すると、この問題を回避できます。

複数のプラットフォームの行末

複数のプラットフォームでパイプラインを実行すると、異なる行末で問題が発生することがあります。伝統的に、Linux と macOS ではラインフィード (LF) 文字が使われ、Windows では復帰とラインフィード (CRLF) が使われてきました。 Git は、リポジトリでは行を自動的に LF で終了するようにし、Windows の作業ディレクトリでは CRLF にすることで、違いを補おうとします。

ほとんどの Windows ツールは LF のみで終わっていても問題なく、この自動動作によって解決されるより多くの問題が発生する可能性があります。行末が基の問題が発生する場合は、すべての場所で LF を優先するよう Git を構成することをお勧めします。これを行うには、リポジトリのルートに .gitattributes ファイルを追加します。そのファイルに、次の行を追加します。

* text eol=lf

' (単一引用符) を含む変数が追加される

##vso コマンドを使用して変数を設定する Bash スクリプトがパイプラインに含まれている場合は、設定した変数の値にさらに ' が追加されることがあります。これは、set -x とのやり取りが原因で発生します。解決策は、変数を設定する前に set -x を一時的に無効にすることです。これを行うための Bash 構文は set +x です。

set +x
echo ##vso[task.setvariable variable=MY_VAR]my_value
set -x

なぜこのようになるのですか?

多くの Bash スクリプトには、デバッグを支援する set -x コマンドが含まれています。 Bash は、実行されたコマンドを正確にトレースして、stdout にエコーします。これにより、エージェントは ##vso コマンドを 2 回認識し、2 回目の Bash の最後には ' 文字が追加されています。

たとえば、次のパイプラインについて考えます。

steps:
- bash: |
    set -x
    echo ##vso[task.setvariable variable=MY_VAR]my_value

エージェントの stdout では、次の 2 つの行が認識されます。

##vso[task.setvariable variable=MY_VAR]my_value
+ echo '##vso[task.setvariable variable=MY_VAR]my_value'

エージェントが最初の行を認識したとき、MY_VAR は "my_value" という正しい値に設定されます。しかし、2 番目の行を認識すると、エージェントは行の最後までのすべてを処理します。 MY_VAR は "my_value'" に設定されます。

スクリプトの実行時に Python アプリケーション用のライブラリがインストールされない

Python アプリケーションが配置されるとき、場合によっては、CI/CD パイプラインが実行されて、コードは正常に配置されますが、すべての依存関係ライブラリのインストールを担当する requirements.txt ファイルは実行されません。

依存関係をインストールするには、App Service 配置タスクで配置後スクリプトを使います。次の例では、配置後スクリプトで使う必要があるコマンドを示します。自分のシナリオ用にこのスクリプトを更新してかまいません。

D:\home\python364x64\python.exe -m pip install -r requirements.txt

サービス接続に関連する問題のトラブルシューティングについては、サービス接続のトラブルシューティングに関連するページを参照してください。

パイプラインがエージェントからの聞き取りを停止しました

パイプラインが失敗し、次のようなメッセージWe stopped hearing from agent <agent name>. Verify the agent machine is running and has a healthy network connection.が表示された場合は、エージェントのリソース使用率をチェックして、エージェントマシンにリソースが不足しているかどうかを確認します。 Sprint 228 以降、Azure Pipelines ログには各ステップのリソース使用率メトリックが含まれています。

Azure DevOps Servicesを使用する場合は、詳細ログをイネーブルにして、ディスク使用率、メモリ使用率、CPU使用率などのリソース使用率をログに表示できます。パイプラインが完了したら、各ステップのエントリをログで検索しますAgent environment resources。

2024-02-28T17:41:15.1315148Z ##[debug]Agent environment resources - Disk: D:\ Available 12342.00 MB out of 14333.00 MB, Memory: Used 1907.00 MB out of 7167.00 MB, CPU: Usage 17.23%

追加のリソース使用率ログのキャプチャについては、リソース使用率の詳細のキャプチャを参照してください。

Storage Explorer を有効にして、Azure Pipelines 経由で Azure DevOps から、.css や .js などの静的コンテンツを静的 Web サイトに配置する

このシナリオでは、Azure ファイルコピータスクを使って、Web サイトにコンテンツをアップロードできます。「コンテンツのアップロード」で説明されている任意のツールを使って、Web コンテナーにコンテンツをアップロードできます。

次のステップ

ログを確認する

パイプラインの実行をトラブルシューティングする

ログを表示する

[エラー分析] ページ

一般的な問題

失敗したパイプライン実行に関するタスクの分析情報

ジョブのタイムアウト

コードのダウンロードに関する問題

パイプラインが checkout ステップで失敗する

Team Foundation バージョン管理 (TFVC) の問題

ソースの取得で一部のファイルがダウンロードされない

Team Foundation プロキシを通したソースの取得

MSBUILD などのコマンドラインステップでパイプラインが失敗する

ファイルのレイアウト

ローカルコマンドプロンプトとエージェントの違い

使用中のファイルまたはフォルダーのエラー

使用中のファイルとフォルダーを検出する

ウイルス対策の除外

MSBuild と /nodeReuse:false

MSBuild と /maxcpucount:[n]

断続的または一貫性のない MSBuild エラー

プロセスが応答を停止する

入力待ち

プロセスダンプ

WiX プロジェクト

複数のプラットフォームの行末

' (単一引用符) を含む変数が追加される

なぜこのようになるのですか?

スクリプトの実行時に Python アプリケーション用のライブラリがインストールされない

パイプラインがエージェントからの聞き取りを停止しました

Storage Explorer を有効にして、Azure Pipelines 経由で Azure DevOps から、.css や .js などの静的コンテンツを静的 Web サイトに配置する

次のステップ

フィードバック

フィードバック

その他のリソース

パイプラインの実行をトラブルシューティングする

ログを表示する

[エラー分析] ページ

一般的な問題

失敗したパイプライン実行に関するタスクの分析情報

ジョブのタイムアウト

コードのダウンロードに関する問題

パイプラインが checkout ステップで失敗する

Team Foundation バージョン管理 (TFVC) の問題

ソースの取得で一部のファイルがダウンロードされない

Team Foundation プロキシを通したソースの取得

MSBUILD などのコマンド ライン ステップでパイプラインが失敗する

ファイルのレイアウト

ローカル コマンド プロンプトとエージェントの違い

使用中のファイルまたはフォルダーのエラー

使用中のファイルとフォルダーを検出する

ウイルス対策の除外

MSBuild と /nodeReuse:false

MSBuild と /maxcpucount:[n]

断続的または一貫性のない MSBuild エラー

プロセスが応答を停止する

入力待ち

プロセス ダンプ

WiX プロジェクト

複数のプラットフォームの行末

' (単一引用符) を含む変数が追加される

なぜこのようになるのですか?

スクリプトの実行時に Python アプリケーション用のライブラリがインストールされない

サービス接続に関連する問題

パイプラインがエージェントからの聞き取りを停止しました

Storage Explorer を有効にして、Azure Pipelines 経由で Azure DevOps から、.css や .js などの静的コンテンツを静的 Web サイトに配置する

次のステップ

フィードバック

フィードバック

その他のリソース

MSBUILD などのコマンドラインステップでパイプラインが失敗する

ローカルコマンドプロンプトとエージェントの違い

プロセスダンプ