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

ルールセットのトラブルシューティング

リポジトリでアクションを実行できず、その理由を知りたい場合は、使用しているブランチまたはタグを対象とするアクティブなルールセットを表示できます。 詳しくは、「リポジトリのルールセットの管理」を参照してください。

アクティブなルールによっては、コミットをリモート ブランチにプッシュするには、コミット履歴をローカルで編集する必要がある場合があります。 たとえば、ブランチでコミットに署名が必要な場合は、署名設定を更新してから、ローカル ブランチで対話型のリベースを使って、署名されたコミットで Git 履歴を書き換えることができます。 詳細については、「ルールセットで使用できるルール」および「コマンドラインで Git リベースを使う」を参照してください。

ブランチまたはタグがコミットのメタデータを制限するルールの対象になっている場合、コミットのメタデータの一部が特定のパターンと一致しない場合、コミットは拒否される可能性があります。 たとえば、コミット メッセージの先頭に Issue 番号を追加したり、リポジトリにプッシュしようとしている新しいブランチまたはタグの名前を変更したりする必要がある場合があります。 コミットが拒否された場合は、関連するメタデータが一致する必要があるパターンを示すメッセージが表示されます。 署名されたコミットと同様に、リベースを実行してコミットをスカッシュするか、各コミットを個別に書き換える必要がある場合があります。 詳しくは、「ルールセットで使用できるルール」を参照してください。

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

ルールセット ワークフローは、プル リクエストを統合する前にワークフローが渡されるように組織レベルで構成できます。 詳しくは、「組織内のリポジトリのルールセットを作成する」を参照してください。

オープン プル リクエストのルールセット ワークフロー

プル リクエストが開いている間にルールを作成した場合、必要なワークフローは自動的には実行されません。 必要なワークフローをトリガーするには、新しいコミットをプッシュするか、ブランチを更新するか、プル リクエストを閉じて再度開きます。

サポートされているルールセット ワークフロー イベント

ルールセット ワークフローでは、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 の設定を管理する」を参照してください。
• ソース リポジトリ内の個々のワークフローを無効にします。 詳細については、「ワークフローの無効化と有効化」を参照してください。

merge_group トリガーの使用

リポジトリで GitHub Actions を使用して、リポジトリ内の pull request において必要なチェックを実行する場合、または組織のルールセットを介するワークフローが必要な場合は、追加のトリガーとして merge_group イベントを含むようにワークフローを更新する必要があります。 それ以外の場合、マージ キューに pull request を追加しても、ステータス チェックがトリガーされません。 必要な状態チェックが報告されないため、マージは失敗します。 merge_group イベントは、pull_request および push イベントとは異なります。

ソース リポジトリの権限

ソース リポジトリの権限が「ORGANIZATION NAME 組織内のリポジトリからアクセス可能」に設定されていることを確認します。

詳しくは、「リポジトリの GitHub Actions の設定を管理する」を参照してください。

ソース リポジトリのプライバシー設定

ルールセットのワークフロー ファイルが、実行するリポジトリと同じまたは制限の緩いプライバシー設定を持つソース リポジトリにあることを確認します。 具体的には、公開用ワークフローは組織内の任意のリポジトリで実行でき、内部ワークフローは内部リポジトリとプライベート リポジトリで実行でき、プライベート ワークフローはプライベート リポジトリで実行できます。 詳しくは、「ワークフローについて」を参照してください。

新しいリポジトリを作成するための権限

ルールセット ワークフローが構成されたときに新しいリポジトリを作成するには、ルールセットのバイパス権限があることを確認します。 詳しくは、「リポジトリのルールセットの作成」をご覧ください。

ルールの分析情報

GitHub は、プル リクエストが統合されるか統合が試行されるまで、ルールの分析情報をログに記録しません。

コンカレンシー

ルールセット ワークフローで cancel-in-progress コンカレンシー設定が使用されていないことを確認します。 コンカレンシーについて詳しくは、「コンカレンシーの使用」をご覧ください。