BEACHSIDE BLOG

Azure と GitHub と C# が好きなエンジニアの個人メモ ( ・ㅂ・)و ̑̑

GitHub の コードオーナー (CODE OWNERS) 機能 マニアックス

GitHub にはコードオーナー (code owners)という機能があります。

コードオーナーを定義することで、プルリクエストがオープンしたときに自動でコードオーナーが Reviewers に追加される機能です。

f:id:beachside:20210813220425p:plain

基本的な設定は理解してましたが、ドキュメントを読むとこんなときはどーなるんだろとか色々疑問を感じたので気になる挙動の確認をしてみました。マニアックスかと問われれば、盛ったぜってタイトルです (汗)。

  • 2021年8月時点の挙動なので、未来では異なる可能性はあります。
  • 挙動の確認は GitHub.com の個人アカウントで試しています (GitHub Enterprise Cloud/Server/AE ではない)。CODE OWNERS の機能に差分はないとは思いますが念のため。

設定方法

まず基本的な話として設定方法をざっくり書いておきます。

repo のルートか、 .github/ (または docs/) の下に CODEOWNERS というファイルを置きます。このファイルの設定は repository の Admin / Owner である必要があります。

f:id:beachside:20210813190405p:plain

あとは CODEOWNERS ファイルで code owner の定義をします。以下がよくある書き方の一例ですが、バリエーションは少ないので公式ドキュメントをみるのが良いです。ルートのフォルダか否かとかサブディレクトリを含めるか否かが必要になったらドキュメント見て確認しておきたいところって感じです。

# 全てを対象
*      @beachside-project

# 拡張子でフィルター
*js    @beachside-project-ghost

# ルートの "docs" フォルダとそのサブディレクトリが対象
/docs/    @beachside-project-ghost2

書く順番も大事で、下に書いたものが優先になります。例えば上記のように書いた場合 *js のファイルは @beachside-project-ghost だけがコードオーナーとして認識され、すべてを対象の @beachside-project はコードオーナーにはなりません。

そのため広い範囲の人を上から書いて、範囲が狭い人を下に書いていく感じになります。あと、複数人定義していた場合はスペース区切りです。

挙動の確認

コードオーナーを定義したときの基本的な挙動を書いてみました。

Owner のマークがつく

Pull request を作成したタイミングで Code owner が自動で Reviewer としてセットされます。Conversations の Reviewer には Owner のマークがつきます。 f:id:beachside:20210813185547p:plain


Pull request の中の File changes を開くとCode owner 対象のファイルはマークがついて、ホバーすると誰が Owner かわかります。

f:id:beachside:20210813185155p:plain

ちなみに Pull request の作成者 = コードオーナーであれば Pull request をオープンしても Reviewers にセットされません。

Reviewers から外すことはできる

後述の「コードオーナーのレビューを必須にする」設定をにした場合、つまり Branch protection rules を設定していた場合は、Reviewers から外すことができません。

Branch protection rules を設定をしてなければ、Reviewers から外すことは普通にできます。

コードオーナーのレビューを必須にする

コードオーナーが Reviewers にセットされても外せるので、必須にしたい場合は、Branch protection rules で対象のブランチに対してルールを追加してあげる必要があります。

ルールは、Require pull request reviews before merging をチェックします。それで展開されて表示される Require review from Code Owners をチェックします。

f:id:beachside:20210813202903p:plain

ざっくりと説明しましたが、branch protection rules の具体的な設定方法については、ドキュメントに記載があります。

保護されたブランチについて - GitHub Docs

コードオーナーのレビューを必須だけどコードオーナー不在のときは?

コードオーナーを必須にしたけど、CODEOWNERS の定義上コードオーナーが存在しない場合は、Required approving reviews の人数の承認があればマージできるようになります。

Pull request のオープン時以外はセットされないの?

ドキュメントでは自動的に Reviewer を追加するのが「Pull request がオープンしたとき」と書かれていますので、Pull request にコミットが追加されたときはどんな挙動になるのか気にになりました。試してみましょう。

Reviewer 不在で Pull request に commit が追加されたら

ここでの想定は、Pull request が既に作られていて CODEOWNERS の定義はされているけど、Pull request の Reviewers にはだれもいない状態です (そんなケースあるのかよって気はしますが検証なのでw) 。その Pull request に対して commit が新たに追加されたらどうなるのでしょうか。

動作を試したところ Branch protection rules の設定で挙動が異なります。

  • Branch protection rules で コードオーナーのレビューが必須のとき
    • Reviewer にコードオーナーが追加されました。このケースが発生するのは Pull request 作成後設定をごにょごにょいじって Reviewer を外し、その後コードオーナーのレビューを必須に戻したときくらいなので超レアなケースです。
  • Branch protection rules で コードオーナーのレビューが必須になってないとき
    • Reviewers に追加されません。うーん、追加されると思ってたけどされないかー。

CODEOWNERS が承認済な状態で新たにコミットが追加されたら

CODEOWNERS レビューが必須の設定かつレビューアーは承認済みの状態で、新規にコミットが追加されたらどうなるかです。

未承認に戻るのかなーと思って試しましたが、結論は承認済みのままでした。

つまりこのケースが発生した場合で再度レビューしてもらいたいときは、コミットを追加した人が手作業で Reviewers にレビューを再リクエスト (Re-request review) する必要があります。

f:id:beachside:20211027174452p:plain

コードオーナー対象の commit が git reset されたらどうなる?

Pull request のオープン時はコードオーナーだったため Reviewers にセットされた人が、commit の一部が git reset されたため対象外になってしまった場合は、自動で Reviewers からは外れません。
ただしコードオーナーのチェックは外れます。

f:id:beachside:20210813211951p:plain

そもそも気軽に git reset すな感はありますがね。

まとめ

あんま変なことを考えなければ便利なものではありますね。 あとは、そもそも Pull request を作ったときはそもそも誰にレビューしてもらいたいかを自己の責任でちゃんとチェックしようと思った今日この頃でした。

参考

About code owners - GitHub Docs