🐧

開発組織の issue や Pull Request を自動で適切な GitHub Project に割り振っていく

2024/07/24に公開

昨日自分の OSS の issue や pull request (以下 PR) を 1 つの GitHub Project に自動で集約して管理するようにしたお話を紹介しました。

昨日導入したばかりですが、今のところかなり良い感じに機能しています。
これを個人の OSS 開発だけに閉じるのはもったいなく、業務でも活用できるはずだと思いました。

今回の記事はその続きで、個人の OSS ではなく業務における開発組織の issue や PR を自動で GitHub Project に追加するようにするお話を紹介します。
やることは前回の記事とほぼ同じですが、皆さんが業務で活用するのをイメージしやすいように具体例を交えながらお話したいと思います。

最初は前回の記事に追記しようかと思いましたが、せっかく追記しても前回の記事のタイトル的に OSS を開発していない人には読んでもらえない可能性がある気がしたので新規に記事を書くことにしました。
前回の記事を読んでいない人はまず読んでください。

あくまで自分の予想ですが、ある程度の規模の開発組織では組織全体で 1 つの Project で管理するというより、 team 毎に Project を分ける場合が多いのではないかと思います。
例えば SRE team 用の Project, Security team 用の Project, A というプロダクトの開発チーム用の Project といった感じです。
また特定のプロジェクト(GitHub Project のことではなく、一般的な用語としてのプロジェクト)用に Project を作ることもあるかもしれません。
例えば Database Migration のためのプロジェクトの issue や PR を管理するために Database Migration という Project を作るといった感じです。

そういった場合に、以下のような条件で issue や PR を自動で適切な Project に追加できると便利でしょう。

team/sre label をつけたら SRE team の Project に追加
SRE team が管理するリポジトリの issue や PR は SRE team の Project に追加
Security team を reviewer として assign したら Security team の Project に追加
project/db-migration label をつけたら Database Migration Project に追加

label に関して言うと、 Renovate などで PR を作る際に team/sre のような label をつけることで SRE が管理する dependency update の PR を SRE team の Project に追加すると言ったことも可能でしょう。

上記のようなことは、以下のような設定ファイルを書いて ghproj を実行すれば実現できるかと思います。

ghproj.yaml

entries:
  - query: |
      is:open archived:false -project:szksh-lab/2
      owner:szksh-lab label:team/sre
    # team/sre label がついてるものは SRE team の Project に追加
    project_id: PVT_SRE0000000000000 # SRE team の Project
  - query: |
      is:open archived:false -project:szksh-lab/2
      repo:szksh-lab/k8s-clusters
      repo:szksh-lab/aws-org
    # SER team が管理するリポジトリ szksh-lab/k8s-clusters, szksh-lab/aws-org の issue, PR は SRE team の Project に追加
    project_id: PVT_SRE0000000000000 # SRE team の Project
  - query: |
      is:open archived:false -project:szksh-lab/2
      owner:szksh-lab is:pr
      team-review-requested:szksh-lab/security
    # Security team を reviewer として assign したら Security team の Project に追加
    project_id: PVT_SECURITY00000000 # Security team の Project
  - query: |
      is:open archived:false -project:szksh-lab/2
      owner:szksh-lab label:project/db-migration
    # `project/db-migration` label をつけたら Database Migration Project に追加
    project_id: PVT_DBMIGRATION00000 # Database Migration Project の Project

reviewer に関しては team-review-requested を使っています。
注意点としては Project に追加される前に team の member の誰かが review をするとクエリに引っかからなくなります。

GitHub の検索は実際に実行してみて試行錯誤する必要があると自分は思っていて、自分は https://github.com の上の検索バーで検索してみて試行錯誤しています。

この仕組みの良いところはリポジトリ毎に個別に設定をする必要がないことです (App を個別にインストールしている場合はインストールが必要ですが)。
新しくリポジトリを作成してもクエリの検索条件に含まれていれば issue や PR が自動で Project に追加されるようになるため、とても楽です。

GitHub App の権限設定などについて

業務ではリポジトリは基本 Private だと思うので GitHub App に Issue や PR への read 権限を付与し Repository にインストールする必要があるでしょう。
各リポジトリには Issue や PR への read 権限のみ付与するので Organization (以下 Org) 全体に App をインストールしてもそこまでリスクは高くないと思います。
Org 全体にインストールしてしまえば個別対応は不要なので楽です。
個別にインストールする場合、対象リポジトリをコード管理できない(管理するための API を GitHub が提供していない)ため App の編集権限を持っている人が Web UI から操作する必要があり、特に大きな組織ではかなり利便性が悪いでしょう。

さいごに

以上、簡単ですが昨日の OSS 開発向けの記事を開発組織でのプロダクト開発向けに補足しました。

残念ながら自分が執筆時点で退職前の有休消化中であるため、今回書いた内容を試すことがまだ出来ていません。
新しい会社に入社したらまずはこの仕組みを導入したいと思います(願望)。

ghproj はとりあえず自分が抱えている目の前の課題(OSS の issue, project 管理)を解決するために作ったので、業務も含めてより広く使っていくにはもっと作り込みが必要だと思っています(まぁ既に使えはしますが)。
他にも色々やることはあるのでどこまで優先度を高く取り組めるか分かりませんが、当初思ってたよりも面白い仕組みな気がするので、なるべく熱いうちに取り組んでいきたいと思います。

GitHub App の権限設定などについて

さいごに

Discussion