トラブルシューティングのワークフロー

メモ

GitHub ホステッドランナーは、現在 GitHub Enterprise Server ではサポートされていません。

初期のトラブルシューティングの提案

ワークフロー実行に失敗した場合、トラブルシューティング方法はいくつかあります。

ワークフロー実行ログの使用

各ワークフローの実行では、表示、検索、ダウンロードできるアクティビティログが生成されます。詳しくは、「ワークフロー実行ログの使用」をご覧ください。

デバッグログを有効にする

ワークフロージョブあるいはステップが期待どおりに動作しない理由を診断する上で、十分な詳細がワークフローのログになかった場合、追加のデバッグロギングを有効化できます。詳しくは、「デバッグログを有効にする」をご覧ください。

ワークフローで特定のツールまたはアクションを使う場合は、デバッグまたは詳細ログオプションを有効にすると、トラブルシューティングのためのより詳細な出力を生成できます。たとえば、npm の場合は npm install --verbose、git の場合は GIT_TRACE=1 GIT_CURL_VERBOSE=1 git ... を使用できます。

ワークフロートリガーのトラブルシューティング

ワークフローの on: フィールドをレビューすることで、ワークフローをトリガーするために想定されることを理解できます。詳しくは、「ワークフローをトリガーする」をご覧ください。

使用できるすべてのイベントの一覧については、「ワークフローをトリガーするイベント」をご覧ください。

発火イベント条件

一部のトリガーイベントは、既定のブランチ (つまり issues、schedule) からのみ実行されます。既定のブランチの外部に存在するワークフローファイルバージョンは、これらのイベントではトリガーされません。

pull request にマージの競合がある場合、pull_request アクティビティではワークフローは実行されません。

コミットメッセージにスキップ注釈が含まれている場合、push または pull_request アクティビティでトリガーされるワークフローはスキップされます。詳しくは、「ワークフロー実行をスキップする」をご覧ください。

予期しない時間に実行されるスケジュールされたワークフロー

スケジュールされたイベントは、GitHub Actions ワークフローの実行によって高い負荷がかかっている間は遅延される可能性があります。

高負荷時間には、毎時の初めが含まれます。負荷が十分に高い場合、キューに登録されたジョブの一部が削除される可能性があります。遅延の可能性を減らすために、Ⅰ時間の中の別の時間帯に実行されるようワークフローをスケジューリングしてください。詳しくは、「ワークフローをトリガーするイベント」をご覧ください。

フィルター処理と差分の制限

一部のイベントでは、カスタマイズ可能なブランチ、タグ、パスによるフィルター処理が可能です。フィルター条件が適用されてワークフローがフィルターで除外される場合、ワークフロー実行の作成はスキップされます。

フィルターには特殊文字を使用できます。詳しくは、「GitHub Actions　のワークフロー構文」をご覧ください。

パスフィルター処理の場合、差分の評価は最初の 300 ファイルに制限されます。フィルターによって返される最初の 300 ファイルと一致しないファイルが変更された場合、ワークフローは実行されません。詳しくは、「GitHub Actions　のワークフロー構文」をご覧ください。

ワークフロー実行のトラブルシューティング

ワークフロー実行には、ワークフローがトリガーされ、ワークフロー実行が作成された後に発生したすべての issue が含まれます。

ワークフローの取り消し

          [UI](/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/canceling-a-workflow) または [API](/rest/actions/workflow-runs?apiVersion=2022-11-28#cancel-a-workflow-run) による標準の取り消しが期待どおりに処理されない場合は、実行中のワークフロー ジョブに対して取り消されない条件付きステートメントが構成されている可能性があります。

このような場合、API を利用して実行を強制的に取り消すことができます。詳しくは、「ワークフロー実行の REST API エンドポイント」をご覧ください。

原因のひとつとして、ステータスチェック機能が取り消し時でもを返す場合が考えられます。 cancelled() 関数の逆関数である ${{ !cancelled() }} を使う方法もあります。

詳細については、「条件を使用してジョブの実行を制御する」および「ワークフローの実行をキャンセルする」を参照してください。