Posted at

GitHubのWebhookとStatus checkでWIP PRのマージを禁止する、という案はありか?

More than 3 years have passed since last update.


TL;DR

sanemat/do-not-merge-wip-for-github で良いと思いました。


GitHub protected branch

protected branch で Status check を有効にする事で、自動テストを通るまでは PR のマージボタンが押せなくなります。

(ベースブランチが先行してしまった場合は、ベースブランチの先行分をブランチにマージして改めてテストを通す必要があったりもします。)

ここで、ふと思いました。

protected branch によって、サーバ(GitHub)側で WIP である PR のマージを禁止することもできるのではないか、と。

それに、どれだけの意味があるかは分かりませんけれども!


GitHub Statuses API

GitHub の Statuses API を使うと、コミットの状態を更新させる事ができます。

GitHub Webhooks でイベントデータを受け取り、結果を Statuses API で反映させるという流れになるのでしょう。

WIP の間は pending とでもしておき、 WIP でなくなったら success とします。


GitHub Webhooks

GitHub のリポジトリなどで発生する各イベントを Webhook に受け取らせることができます。

Webhook は任意の URL で設定可能で、POST で json を受け取る様な形になります。

PR が WIP であるかの判断基準は、「タイトルに [WIP] の様なマークが含まれている」としておきます。

PR のタイトルを確認可能な Webhook イベントは、 pull_requestpull_request_review_comment だけの様です。

pull_request_review_comment は diff に対するコメントが付いたときなので、今回は見送ります。

pull_request イベントは、以下の様なアクションで細分化されます。


  • “assigned”

  • “unassigned”

  • “labeled”

  • “unlabeled”

  • “opened”

  • “closed”

  • “reopened”

  • “synchronize”

お気づきでしょうか?

はい、そうです。「PRのタイトルを変更した」時にはイベントは発生しない様なのです。

完。

もう少しだけ、続きます。


実験アプリ

GitHub Webhooks も GitHub API もまともに触ったことがなかったので、思いついたままに突き進むことにしました。

タイトル変更をトリガーにできない(方法が分からない)ので、無駄に制約を増やしてしまうこのアプリ、無駄の極みです。

必要に応じて、各自で Do Not Merge WIP for GitHub の様なブラウザ確証を使うのが妥当なのではないでしょうか。

なお、一般に、 WIP PR のマージ防止に気をつかっているのか、どう気をつかっているのか、について知見はありません!


WIP 判定チャンス

GitHub の pull_request イベントを対象に、各アクションで WIP かどうかの判定を行う様にしてみます。


closed

PR を閉じた時は無視します。


opened, reopened

PR を作った時、開き直した時は、 WIP 判定のチャンスです。

タイトルに WIP らしき情報が入っているか判定します。

アクションが reopened である場合、既にマージされているかもしれないので、 merged キーの値も確認するべきでしょう。


synchronize

ブランチに push したタイミングで発生する様です。

opened アクション同様にタイトル判定チャンスと考えます。


updated due to a new push in the branch that the pull request is tracking



assigned, unassigned

タイトル変更は検知できませんが、タイトルから WIP を外すと同時にレビュアーに担当者を変更するかもしれません。いいや、そのはずだ。

PR の担当者が変わるタイミングがタイトルでの判定チャンスです。


labeled, unlabeled

タイトル変更を検知できないため、タイトルによる WIP 運用を諦めてラベルによる WIP 運用を行いましょう。

WIP ラベルが付いた時、 WIP ラベルが外され時が判定チャンスです。


Status check

Webhook で受け取ったイベントデータを使って WIP 判定をしたら、その結果を GitHub Statuses API を使ってコミットに反映させます。

WIP なら pending とし、 WIP でないなら success とします。


まとめ

GitHub Webhooks の実験道具を作りました。

GitHub リポジトリの Webhooks のページからどんなイベントデータ(ペイロード)が送られているのかを見られる様になります!