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

GitHub Actionsのツールを使用して、ワークフローをデバッグできます。

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

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

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

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

各ワークフローの実行では、表示、検索、ダウンロードできるアクティビティ ログが生成されます。 詳しくは、「[ワークフロー実行ログの使用](/ja/enterprise-server@3.22/actions/how-tos/monitor-workflows/use-workflow-run-logs)」をご覧ください。

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

ワークフロージョブあるいはステップが期待どおりに動作しない理由を診断する上で、十分な詳細がワークフローのログになかった場合、追加のデバッグロギングを有効化できます。 詳しくは、「[デバッグ ログを有効にする](/ja/enterprise-server@3.22/actions/how-tos/monitor-workflows/enable-debug-logging)」をご覧ください。

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

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

最初に、ワークフローが手動で無効になっていないことを確認します。 [ワークフローの無効化と有効化](/ja/enterprise-server@3.22/actions/how-tos/manage-workflow-runs/disable-and-enable-workflows) を参照してください。 無効なワークフローは、そのトリガーに応答しません。

ワークフローの `on:` フィールドをレビューすることで、ワークフローをトリガーするために想定されることを理解できます。 詳しくは、「[ワークフローをトリガーする](/ja/enterprise-server@3.22/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow)」をご覧ください。

使用できるすべてのイベントの一覧については、「[ワークフローをトリガーするイベント](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows)」をご覧ください。

### 発火イベント条件

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

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

コミット メッセージにスキップ注釈が含まれている場合、`push` または `pull_request` アクティビティでトリガーされるワークフローはスキップされます。 詳しくは、「[ワークフロー実行をスキップする](/ja/enterprise-server@3.22/actions/how-tos/manage-workflow-runs/skip-workflow-runs)」をご覧ください。

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

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

高負荷時間には、毎時の初めが含まれます。 負荷が十分に高い場合、キューに登録されたジョブの一部が削除される可能性があります。 遅延の可能性を減らすために、Ⅰ時間の中の別の時間帯に実行されるようワークフローをスケジューリングしてください。 詳しくは、「[ワークフローをトリガーするイベント](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule)」をご覧ください。

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

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

フィルターには特殊文字を使用できます。 詳しくは、「[GitHub Actions　のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet)」をご覧ください。

パス フィルター処理の場合、差分の評価は最初の 300 ファイルに制限されます。 フィルターによって返される最初の 300 ファイルと一致しないファイルが変更された場合、ワークフローは実行されません。 詳しくは、「[GitHub Actions　のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#git-diff-comparisons)」をご覧ください。

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

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

### ワークフローの取り消し

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

このような場合、API を利用して実行を強制的に取り消すことができます。 詳しくは、「[ワークフロー実行の REST API エンドポイント](/ja/enterprise-server@3.22/rest/actions/workflow-runs?apiVersion=2022-11-28#force-cancel-a-workflow-run)」をご覧ください。

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

詳細については、「[条件を使用してジョブの実行を制御する](/ja/enterprise-server@3.22/actions/how-tos/write-workflows/choose-when-workflows-run/control-jobs-with-conditions)」および「[ワークフローの実行をキャンセルする](/ja/enterprise-server@3.22/actions/how-tos/manage-workflow-runs/cancel-a-workflow-run)」を参照してください。

## ランナーの問題解決

### ランナーラベルを定義する

GitHubホストランナーは、[](/ja/enterprise-server@3.22/actions/reference/runners/github-hosted-runners) リポジトリで保持される`actions/runner-images`を利用します。

大規模なセルフホステッド ランナーには、一意のラベル名を使うことをお勧めします。 ラベルが既存のプリセット ラベルのいずれかと一致する場合、どの一致するランナー オプションでジョブが実行されるかが保証されず、ランナーの割り当てに関する issue が発生する可能性があります。

### セルフホステッド ランナー

セルフホスト ランナーを使用する場合、そのアクティビティを見て、一般的な問題を診断できます。

詳しくは、「[自己ホストランナーのモニタリングとトラブルシューティング](/ja/enterprise-server@3.22/actions/how-tos/manage-runners/self-hosted-runners/monitor-and-troubleshoot)」をご覧ください。

## ネットワークのトラブルシューティングの提案

以下のネットワークの問題については、サポートが限定されます。

* あなたのネットワーク
* 外部ネットワーク
* サード パーティ製システム
* 一般的なインターネット接続

GitHubのリアルタイム プラットフォームの状態を表示するには、[GitHub状態](https://githubstatus.com/)を確認します。

その他のネットワーク関連の問題については、organization のネットワーク設定をレビューし、アクセスしているサード パーティ サービスの状態をレビューします。 問題が解決しない場合は、ネットワーク管理者に連絡してサポートを受けることを検討してください。

問題が不明な場合は、 GitHub のサポートにお問い合わせください。 サポートへの連絡方法の詳細については、「[GitHub Support へのお問い合わせ](/ja/enterprise-server@3.22/support/contacting-github-support)」を参照してください。

### DNS

ドメイン ネーム システム (DNS) の構成、解決、またはリゾルバーの問題が原因で問題が発生する可能性があります。 使用できるログやベンダーのドキュメントをレビューするか、管理者に問い合わせて追加のサポートを受けることをお勧めします。

### ファイアウォール

ファイアウォールによってアクティビティが禁止される可能性があります。 このような問題が発生した場合は、使用できるログやベンダーのドキュメントをレビューするか、管理者に問い合わせて追加のサポートを受けることをお勧めします。

### プロキシ

通信にプロキシを使うとアクティビティが失敗する可能性があります。 使用できるログやベンダーのドキュメントをレビューするか、管理者に問い合わせて追加のサポートを受けることをお勧めします。

プロキシを利用するためのランナー アプリケーションの構成については、「[ランナーでのプロキシサーバの使用](/ja/enterprise-server@3.22/actions/how-tos/manage-runners/use-proxy-servers)」を参照してください。

### サブネット

仮想クラウド プロバイダーや Docker ネットワーク内など、使用中のサブネットや既存のネットワークとの重複により問題が発生する可能性があります。 このような場合は、ネットワーク トポロジと使用中のサブネットをレビューすることをお勧めします。

### 証明書

自己署名またはカスタムの証明書チェーンおよび証明書ストアが原因で問題が発生する可能性があります。 使用中の証明書の有効期限が切れておらず、現在信頼されているかどうかをチェックできます。 証明書は `curl` または同様のツールを使って検査できます。 使用できるログやベンダーのドキュメントをレビューするか、管理者に問い合わせて追加のサポートを受けることもできます。

### IP リスト

IP 許可リストまたは拒否リストにより、想定される通信が中断される可能性があります。 問題がある場合は、使用できるログやベンダーのドキュメントをレビューするか、管理者に問い合わせて追加のサポートを受ける必要があります。

### オペレーティング システムとソフトウェア アプリケーション

ファイアウォールやプロキシに加えて、追加のソフトウェア パッケージのインストールなど、 GitHubホストランナーに対して実行されるカスタマイズにより、通信が中断される可能性があります。 使用できるカスタマイズ オプションの詳細については、「[GitHubホストランナーのカスタマイズ](/ja/enterprise-server@3.22/actions/how-tos/manage-runners/github-hosted-runners/customize-runners)」を参照してください。

* セルフホステッド ランナーの場合は、「[セルフホステッド ランナー リファレンス](/ja/enterprise-server@3.22/actions/reference/runners/self-hosted-runners)」で必要なエンドポイントの詳細を確認します。

* WireGuard の構成については、「[WireGuard を使用してネットワーク オーバーレイを作成する](/ja/enterprise-server@3.22/actions/how-tos/manage-runners/github-hosted-runners/connect-to-a-private-network/connect-with-wireguard)」を参照してください。

* OpenID Connect (OIDC) の構成の詳細については、「[OIDC とともに API ゲートウェイを使用する](/ja/enterprise-server@3.22/actions/how-tos/manage-runners/github-hosted-runners/connect-to-a-private-network/connect-with-oidc)」を参照してください。