GitHubのプルリクのレビュワーを自動でいい感じに指名するプログラムを作った |

Blog

2017.1.24

GitHubのプルリクのレビュワーを自動でいい感じに指名するプログラムを作った

Dynalystの黒崎です。

GitHubのプルリクのレビュワーが自動で指名されるようになったら便利だろうかと思い、作って導入してみたので紹介します。

GitHubのレビュワー機能

ご存知の方も多いとは思いますが、GitHubにはプルリクエストのレビュワーを指名する機能があります。 (About pull request reviews)

画像の引用元: About pull request reviews

この機能があれば画像のように、レビュワーとして指定したユーザからOKが貰えるまでプルリクエストのマージがブロックされる仕組みです。

レビュワーをどうやって選ぶのか

誰かから依頼を受けて作業をした場合は、レビュワーとしてその人を指名する事が多いと思いますが、それ以外の場合はどうでしょうか。
自分が変更を加えた箇所の周辺をコミットした事がある人が詳しい可能性が高いので、その人に依頼する事が多いのではないでしょうか。

そう思っていたところ、LINEのエンジニアブログでgitのコミットログを用いてレビュワーを探すスクリプトの記事がありました。
git で reviewer を探すスクリプトを作りました/LINE Engineers’ Blog

簡単に言うと、

変更されたファイルに詳しい人が、レビュアーとして選出される。
変更されたすべてのファイルで、レビュアーの誰かがレビューできる。
無駄にレビュアーを増やさない。

というアルゴリズムです。

これを試しに実行してみたところ、おおよそ納得のいきそうなレビュワー候補が上がってきたので、このスクリプトをベースにGitHubのプルリクエストに対応させてレビュワーをアサインするところまで自動化してみました。

作ったプログラム

kurochan/github_reviewer_assignor

自分で書いたのは200行もないくらいですが、GitHubのAPIがわかりやすくて簡単なおかげですぐ作ることができました。

使い方

必要なのはgitとruby(試した環境は2.3)とoctokitというGitHub APIのラッパーのgemです。
config.rbにGitHubのAPIキーやgitのコミットログのメールアドレスとGitHubのユーザIDの対応を記述します。
GitHubのAPIでメールアドレスからGitHubのユーザIDが紐付けられればよかったのですが、できなかったのと、GitHubに登録していないメールアドレスでコミットされたものもたまに混じっていたりするので設定で持つことにしました。

$ sudo apt -y install ruby git-core
$ sudo gem install octokit
$ git clone https://github.com/kurochan/github_reviewer_assignor
$ cp github_reviewer_assignor/config.rb{.example,}
# edit config file
$ vim github_reviewer_assignor/config.rb

$ ruby github_reviewer_assignor/main.rb

$ sudo apt -y install ruby git-core

$ sudo gem install octokit

$ git clone https://github.com/kurochan/github_reviewer_assignor

$ cp github_reviewer_assignor/config.rb{.example,}

# edit config file

$ vim github_reviewer_assignor/config.rb

$ ruby github_reviewer_assignor/main.rb

実行すると、レビュワーが付いていないプルリクエストに対して、そのブランチをGitHubからfetchしてきて、ローカルでコミットの差分を取ってレビュワー候補(のメールアドレス)を出します。メールアドレスとGitHubユーザIDのマッピングがあればGitHub APIを叩いてそのユーザをレビュワーとして設定します。

今のところイベントをフックしたりはしていないので、cronで定期的に実行されるようにしています。

実際に使ってみる

先週より自分のチームの一部リポジトリで動かしはじめたので、”それっぽく”動いているのはわかりますが、”いい感じ”にアサインできているのかはまだわかりません。。。
ぱっと見た感じ、同じ人がアサインされていて、チーム歴が長い(コミット量が多い)人ほどレビューの負荷が偏ってしまう気がしてきているので、そのあたりはレビューの実績を記録して、レビュー回数で分散されるようにしたり工夫が必要かもしれません。

しばらく動かして、新たに知見が得られたらまた記事を書こうと思います。

Author

kurochan