ルールセットのトラブルシューティング
リポジトリでアクションを実行できず、その理由を知りたい場合は、使用しているブランチまたはタグを対象とするアクティブなルールセットを表示できます。 詳しくは、「リポジトリのルールセットの管理」をご覧ください。
アクティブなルールによっては、コミットをリモート ブランチにプッシュするには、コミット履歴をローカルで編集する必要がある場合があります。 たとえば、ブランチでコミットに署名が必要な場合は、署名設定を更新してから、ローカル ブランチで対話型のリベースを使って、署名されたコミットで Git 履歴を書き換えることができます。 詳細については、「ルールセットで使用できるルール」および「コマンドラインで Git リベースを使う」を参照してください。
ブランチまたはタグがコミットのメタデータを制限するルールの対象になっている場合、コミットのメタデータの一部が特定のパターンと一致しない場合、コミットは拒否される可能性があります。 たとえば、コミット メッセージの先頭に Issue 番号を追加したり、リポジトリにプッシュしようとしている新しいブランチまたはタグの名前を変更したりする必要がある場合があります。 コミットが拒否された場合は、関連するメタデータが一致する必要があるパターンを示すメッセージが表示されます。 署名されたコミットと同様に、リベースを実行してコミットをスカッシュするか、各コミットを個別に書き換える必要がある場合があります。 詳しくは、「ルールセットで使用できるルール」をご覧ください。
プッシュ ルールセットを利用する場合、1 回のプッシュにつき最大 1,000 件の参照更新を実行できます。 プッシュがこの制限を超えると、拒否されます。 詳しくは、「リポジトリのルールセットの作成」をご覧ください。
必須ステータスチェックのトラブルシューティング
ステータス チェックを定義する場合、名前の形式はチェックの種類によって異なります。
- Workflow: 名前の形式は
<job name>です。 - Reusable workflow: 名前の形式は
<job name> / <reusable job name>です。 - Other checks: 名前の形式は
<check name>です。
必須のステータス チェックでは、ワークフロー、マトリックス、またはイベント トリガーの種類は考慮されません。
リポジトリ レベルより上位で定義されたルールセットに対しては、ステータス チェックはインデックスが作成されません。 想定される正確なチェック名を手動で入力する必要があります。
評価モードのルールセットの場合、対象のブランチに対してステータス チェックが実行されますが、合格する必要はありません。
ルールセット ワークフローのトラブルシューティング
ルールセット ワークフローは、プル リクエストを統合する前にワークフローが渡されるように組織レベルで構成できます。 詳しくは、「組織内のリポジトリのルールセットを作成する」をご覧ください。
オープン プル リクエストのルールセット ワークフロー
プル リクエストが開いている間にルールを作成した場合、必要なワークフローは自動的には実行されません。 必要なワークフローをトリガーするには、新しいコミットをプッシュするか、ブランチを更新するか、プル リクエストを閉じて再度開きます。
サポートされているルールセット ワークフロー イベント
ルールセット ワークフローでは、pull_request、pull_request_target および merge_group イベントの使用がサポートされます。 その結果、ワークフローがルールセットによって実行されるように、ワークフローの on: セクションで、これらのイベントのうち 1 個以上を指定する必要があります。
サポートされているイベントに対して指定したフィルターは無視されます - 例: branches、 branches-ignore、 paths など types。 ワークフローは、サポートされているイベントの既定のアクティビティの種類によってのみトリガーされ、すると常に作動します。
| イベント | 既定のアクティビティの種類 |
|---|---|
pull_request | opened, synchronize, reopened |
pull_request_target | opened, synchronize, reopened |
merge_group | checks_requested |
詳しくは、「ワークフローをトリガーするイベント」をご覧ください。
ルールセット ワークフローは、GITHUB_TOKEN によってトリガーされたイベントで実行されます。 詳しくは、「自動トークン認証」をご覧ください。
リポジトリの作成のブロック
ワークフローは初期化されているリポジトリに対して実行できないため、必要なワークフローにより、リポジトリが作成されるをブロックする場合があります。 これを回避するには、ルールセットの適用状態を [評価] と設定するか、バイパス アクセス許可を持つユーザーがリポジトリを作成してブランチ保護をバイパスする必要があります。
適用ステータスと「評価」モードの詳細については、「リポジトリのルールセットの作成」を参照してください。
バイパス権限の詳細については、「保護されたブランチについて」を参照してください。
ルール セット内の分岐ターゲット
ルールセット ワークフローがリポジトリ内のすべてのブランチを対象としていないことを確認します。 ブランチに対するすべての変更が、プル リクエストによって実行されるブランチのみをターゲットにする必要があります。
サポートされているディレクトリ
ワークフロー ファイルが .github/workflows ディレクトリに存在することを確認します。 ソース リポジトリではないリポジトリ内の pull_request イベントに対してルールセット ワークフローを実行する場合は、次のいずれかのアクションを実行できます:
- 条件を
if: trueなどのワークフロー ファイルに追加します。 詳しくは、「GitHub Actions のワークフロー構文」をご覧ください。 - ソース リポジトリでアクションを完全に無効にします。 詳しくは、「リポジトリの GitHub Actions の設定を管理する」をご覧ください。
- ソース リポジトリ内の個々のワークフローを無効にします。 詳しくは、「ワークフローの無効化と有効化」をご覧ください。
merge_group トリガーの使用
リポジトリで GitHub Actions を使用して、リポジトリ内の pull request において必要なチェックを実行する場合、または組織のルールセットを介するワークフローが必要な場合は、追加のトリガーとして merge_group イベントを含むようにワークフローを更新する必要があります。 それ以外の場合、マージ キューに pull request を追加しても、ステータス チェックがトリガーされません。 必要な状態チェックが報告されないため、マージは失敗します。 merge_group イベントは、pull_request および push イベントとは異なります。
ソース リポジトリの権限
ソース リポジトリの権限が「ORGANIZATION NAME 組織内のリポジトリからアクセス可能」に設定されていることを確認します。
詳しくは、「リポジトリの GitHub Actions の設定を管理する」をご覧ください。
ソース リポジトリのプライバシー設定
ルールセットのワークフロー ファイルが、実行するリポジトリと同じまたは制限の緩いプライバシー設定を持つソース リポジトリにあることを確認します。 具体的には、公開用ワークフローは組織内の任意のリポジトリで実行でき、内部ワークフローは内部リポジトリとプライベート リポジトリで実行でき、プライベート ワークフローはプライベート リポジトリで実行できます。 詳しくは、「ワークフローについて」をご覧ください。
新しいリポジトリを作成するための権限
ルールセット ワークフローが構成されたときに新しいリポジトリを作成するには、ルールセットのバイパス権限があることを確認します。 詳しくは、「リポジトリのルールセットの作成」をご覧ください。
ルールの分析情報
GitHub は、プル リクエストが統合されるか統合が試行されるまで、ルールの分析情報をログに記録しません。
コンカレンシー
ルールセット ワークフローで cancel-in-progress コンカレンシー設定が使用されていないことを確認します。 コンカレンシーの詳細については、「ワークフローとジョブのコンカレンシーを制御する」を参照してください。