
pull_request イベントでトリガーされるはずの GitHub Actions ワークフローが実行されない時は、プルリクエストに競合が無いか確認しよう
こんにちは、製造ビジネステクノロジー部の若槻です。
GitHub Actions のワークフローを設定しているにも関わらず、プルリクエスト(PR)作成時に pull_request
イベントでトリガーされるはずのワークフローが実行されないことがあります。この問題に遭遇した場合、意外と見落としがちな原因の一つとして「マージ競合(コンフリクト)」があります。今回はこの問題と解決策について解説します。
事象
次のような pull_request
イベントをトリガーとしたワークフローが作成されたリポジトリがあります。
name: CI
on: pull_request
jobs:
Integration:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
# ...
このリポジトリに対して、PR を作成したとき、上記のワークフローが実行されません。
ちなみに上記では表示されていませんが、チェックステータス一覧にはWaiting for status to be reported
というメッセージも表示されます。
原因、解決
原因は、pull_request
イベントは、PRにマージの競合(コンフリクト)がある場合、ワークフローは実行されないためです。
ドキュメントには次のように記載されています。
- pull request にマージの競合がある場合、
pull_request
アクティビティではワークフローは実行されません。マージの競合を最初に解決する必要があります。逆に、pull_request_target
イベントを含むワークフローは、pull request にマージの競合がある場合でも実行されます。pull_request_target
トリガーを使う前に、セキュリティ リスクに注意する必要があります。詳細については、pull_request_target を参照してください。
と言うわけで、先ほどのPRでコンフリクトを解決すると、ワークフローが実行されるようになりました。
pull_request_target イベントは使わなくても良さそう
それでは pull_request
ではなく pull_request_target
イベントを使用して、PRに競合がある場合でもワークフローを実行するべきかと言うと、あまりお勧めできないです。
前述のドキュメントの記載の通り、pull_request_target
イベントはセキュリティリスクがあるためです。このイベントはベースブランチのコンテキストで実行され、リポジトリのシークレットに完全にアクセス可能となります。要するに信頼できないPRのコードを、リポジトリの完全な権限を持った状態で実行することになり、攻撃者がシークレットにアクセスできる可能性が生じます。
よって、通常の開発ではトリガーには pull_request
イベントを使用し、プルリクエストにある競合は即座に解決する方針とするのが良いでしょう。
おわりに
GitHub Actions のワークフローが実行されない場合、意外と見落としがちな原因として「プルリクエストにマージの競合がある」ことがあります。皆さんも、PRを作成した際にワークフローが実行されない場合は、まずはコンフリクトの有無を確認してみてください。
以上