name: Base Changes Check
on:
pull_request:
types:
- opened
- edited # プルリクのbaseブランチを変更した際にもチェック
- reopened
- synchronize
concurrency: # イベントの発行順どおりに実行(今回はeditのような画面操作もあるので)
group: ${{ github.workflow }}-${{ github.head_ref }}
cancel-in-progress: true
jobs:
check:
name: Changes check
runs-on: ubuntu-latest
permissions:
contents: read # for yumemi-inc/path-filter
steps:
- name: Compare pull request head and tentative merge commit
uses: yumemi-inc/path-filter@v2
with:
head-ref: ${{ github.event.pull_request.head.sha }}
base-ref: ${{ github.sha }}
patterns: '**' # 全ファイルを対象（フィルターはしない）
run: |
echo '::error::Head branch does not contain latest base branch changes.' && exit 1
yumemi-inc/path-filter action を用いて、プルリクの head コミット（github.event.pull_request.head.sha）のコードと、仮マージコミット（github.sha）のコードに差分があるかを確認し、差分がある場合はワークフローを落としています。yumemi-inc/path-filter は本来は拡張子等でフィルターする為の action なのですが、今回は何かしらの差分があるかの確認で利用する為、patterns input に ** を指定しフィルターはしないようにしています。
同様の対策はこのワークフロー以外にリポジトリの設定でもでき、具体的にはリポジトリのブランチ保護ルールまたは Rulesets の設定で [Require status checks to pass before merging] - [Require branches to be up to date before merging] にチェックをつけることで、base ブランチが進んでいる場合は画面にその旨の表示されつつ、マージボタンは非活性になります。上記のワークフローと併用で、このリポジトリの設定もしておくとよいでしょう。このリポジトリの設定の場合、ステータスをチェックする job を最低限ひとつ選択しないと（上記のワークフローの job でも別の job でも何でもいいです）、この設定は有効にならないので注意です。
普段の開発では多少、base ブランチが進んでいても大きな問題にはならないかもしれませんが、例えば git-flow などで数ヶ月ぶりにリリースを行うような場合、main ブランチへのマージのプルリクエストには数百のファイルが含まれるという事はよくあると思います。そういった際、このようなワークフローで main ブランチと、 release ブランチや develop ブランチとの間に差異がないことが担保されていると、安心してマージできるかと思います。このワークフローが落ちた場合は、過去の main ブランチに対して行われた修正を develop ブランチに反映し忘れていたということなので、main ブランチを develop にマージして、QA やリリース作業をやり直すことになるかと思います。リリース直前でこのようなことをバタバタしていると大変なので、早い段階で draft で、main ブランチ向けのマージプルリクを作っておいて、上記のワークフローを回しておくという手もあるかと思います。
上記のワークフローを用意しなくても、リポジトリのブランチ保護ルールまたは Rulesets の設定だけでも十分、という話もありますが、プルリクに数十、数百のファイルが含まれていると何となく不安になり approve も躊躇してしまうので、main ブランチに対するマージのみでも、上記のようなワークフローによるファイルベースの比較がされているとレビュアーにとってより安心かなと思います。
Discussion