よくある例
GitHub ActionsでCD（継続的デリバリー／デプロイ）フローを構築する際、
pull_requestイベント（closed）をトリガーに設定し、PRをマージしたタイミングでデプロイを実行する構成を採用するケースは少なくありません。
on:
pull_request:
types:
- closed
branches:
- develop
- staging
- production
jobs:
deploy:
if: ${{ github.event.pull_request.merged == true }}
一見すると問題なさそうに見えますが、運用上のリスクや制約が存在します。
想定外のデプロイが発生する可能性
pull_requestイベントのclosedは、マージされなかったPRでも発火します。
そのため、条件を設定し忘れると意図しないデプロイが実行される可能性があります。
これを防ぐために毎回下記のように記述する必要があります。
if: ${{ github.event.pull_request.merged == true }}
ジョブ数が増えると、この条件を全てに記載しなければならず、メンテナンス性が低下します。
手動実行（workflow_dispatch）との相性が悪い
pull_request.mergedの条件を設定した場合、そのままではworkflow_dispatchによる手動実行が動作しません。
手動実行とマージ判定の両方に対応させるには、以下のような条件式が必要になります。
if: ${{ github.event_name == 'workflow_dispatch' || github.event.pull_request.merged == true }}
条件が複雑化し、可読性が低下します。
pushイベントへの置き換え
これらの問題を回避するには、pushイベントをトリガーとする方法が有効です。
on:
push:
branches:
- develop
- staging
- production
pushイベントであれば、ブランチの最新状態がそのままデプロイ対象となり、条件設定やマージ可否判定の煩雑さを排除できます。
また、副次的な利点として、pushイベントを採用しておくと、将来的にタグ駆動型デプロイへ移行する際も設定変更が容易です。
まとめ
-
pull_requestイベントは条件漏れや手動実行の制約により運用が複雑化しやすい -
pushイベントは構成が簡潔で安全性が高く、将来の運用変更にも柔軟に対応可能
既存ワークフローを変更するほどのメリットはありませんが、新規にCDフローを構築する場合は、pushイベントを利用すると幸せになれるかもしれません。
なお、本記事で扱っているのは CD（継続的デリバリー／デプロイ） におけるフローの話です。
一方で、CI（継続的インテグレーション）の観点では、push ではなく pull_request トリガーを扱う方が適しています。
両者は目的が異なるため、混同しないようにご注意ください。
Discussion