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

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

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

メモ

GitHub Copilot Free サブスクリプションを利用している場合、これは毎月のチャットメッセージ制限にカウントされます。

GitHub Copilot の使用

失敗したワークフロー実行に関する GitHub Copilot とのチャットは、次のいずれかで開くことができます。

マージボックス内の失敗したチェックの横にあるをクリックしてから、[ Explain error] をクリックします。
マージボックスで、失敗したチェックをクリックします。ワークフロー実行の要約ページの上部にある [ Explain error] をクリックします。

GitHub Copilot とのチャットウィンドウが開き、issue を解決する手順が表示されます。

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

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

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

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

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

課金エラーのレビュー

Actions の使用には、ランナーの時間 (分) と、ワークフロー成果物のストレージが含まれます。詳しくは、「GitHub Actions の課金」をご覧ください。

予算の設定

Actions の予算を設定すると、課金またはストレージのエラーが原因で失敗したワークフローのブロックをすぐに解除できることがあります。設定した予算額まで、追加の時間 (分) とストレージ使用量に対して課金されます。詳細については、「従量制課金製品の支出を管理するための予算の設定」を参照してください。

メトリックを使った GitHub Actions アクティビティのレビュー

メトリックを使用してワークフローの効率と信頼性を分析するには、「GitHub Actions メトリックの表示」を参照してください。

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

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

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

トリガーイベントの条件

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

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

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

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

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

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

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

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

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

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

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

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

ワークフローの取り消し

UI または API による標準の取り消しが期待どおりに処理されない場合は、実行中のワークフロージョブに対して取り消されない条件付きステートメントが構成されている可能性があります。

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

一般的な原因としては、取り消した場合でも true が返される always() ステータスチェック関数を使っている場合が考えられます。 cancelled() 関数の逆関数である ${{ !cancelled() }} を使う方法もあります。

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