株式会社トラストバンク・プロダクト開発部の @sakataku1991 です。
この記事は トラストバンク Advent Calendar 2024 の4日目の記事です。
トラストバンクには2024年の11月に入社。
現在はフロントエンドの開発を担当しています。
今回は日頃 GitHub を利用する中で感じた課題を解決するべく、簡単な GitHub Actions のコードを作成したので、そのコード作成の経緯や目的、思考の筋道などを一本の記事として全部まとめてみようと思います。
チーム開発の中で感じた課題
既存のコードを読む際に、ファイル→コード→そのコードの開発者→その開発者が書いたその他のコード、という順で過去の実装内容や開発意図をたどる場面がありました。その際、PR に Assignee（PR の担当者）が設定してあれば関連する PR やその担当者の方が過去ほかに担当した PR をまとめて参照することができ、大変ありがたかったです。
また、PR の一覧ページを見た際にその PR の開発者のアイコンが表示されていれば単純にぱっと見で判別しやすいというのもあります。
しかし、GitHub の Assignee はデフォルトでは PR 作成者が手動で設定する必要があり、自動的には設定されません。そのため Assignee が設定されている PR と Assignee が設定されていない PR とが混在しているような状況でした。
そこで私はどうにかこの PR 作成時の Assignee の設定漏れをなくす、あるいは、Assignee の設定を強制するような仕組みを構築することができないか？と思い、この課題を解決するための方法を調査し始めました。
そもそもの実現したいこと
まずはじめに実現したいことの本質を深掘りつつ、それを実現するための手段を明確にすることにしました。
こうであってほしいということ
- 何か新しい実装を進める際に、関連する過去の実装をたどりやすくしたい
- 過去の実装（＝PR）を「開発者」によって絞り込めるようにしたい
- PR に必ず Assignee が設定されているようにすることで、「開発者」を条件とした PR の絞り込み検索ができるようにしたい
- PR と開発者とを明示的に1対1で紐付けておくことで、既存コードの実装内容や開発意図が容易にたどれるような状態にしたい
- 過去の実装（＝PR）を「開発者」によって絞り込めるようにしたい
ひとまず、ふわっとしたイメージしかなかった「やりたいこと・理想の状態」をカチッと言語化。これを元に「やりたいこと」を実現するための手段を考えていきます。
実現方法の案
- PR 作成時に Assignee の設定を必須とするようなバリデーションをかけられないか？
- Assignee が設定されるまで PR の作成が完了できないように制御することはできるのか？
- PR 作成時に Assignee が自動で設定されるようにすることができないか？
- ↑こちらの場合、PR の作成者イコールその PR の Assignee で設定してしまって問題なさそう
今回ぱっと思い付いた解決策は上記の2案でした。
Assignee の設定が、
- どのタイミングで？
- どういった方法で？
行なわれると一番いいのか？
まず、Assignee 設定のタイミングは PR の作成と同時でよさそうです。
次にどういった方法で Assignee が設定されるのがいいか？ですが、これはなるべく人の手を煩わせたくない、ワンクリックでも操作の手間を減らすべきということで、機械的・自動的に設定するのが理想だと考えました。
なのでこちらは 2 の実現方針を採用することにしました。
採用した実現方針
- 2 の案
- リポジトリに何らかの設定を加えることにより、PR の Assignee が自動設定されるようにしたい
実現するために必要な作業は何か？
以前、GitHub の Team 機能を利用して PR のレビュアーが自動割り当てされる設定をしたことがありました。
これと同じように Assignee の自動割り当てもリモートリポジトリ（GitHub）のどこかのページで設定することができないか？と考えました。
...が、「Teams」ページや「Pull requests」ページ、「Settings」ページなど、設定項目がありそうなページをいくら見てもそれらしきものはどこにもありません。
ググってみると、どうも GitHub Actions を使うことで Assignee の自動割り当てができるようになるらしく。
正直これくらいの機能であれば GitHub の GUI でそういう設定させてくれよと思わなくもなかったのですが、GitHub Actions の作り方の勉強にもなるので今回はこのやり方を採用することにしました。
採用した実現方法
- GitHub Actions を利用し、PR の Assignee が自動的に割り当てられるようにする
...というわけで、ここでようやく今回作成したコードの登場です。
今回作成したコード（ymlファイル）
# PRのAssigneesを自動的に設定する
name: Auto Assign PR Assignees
on:
# このワークフローをトリガーするイベント
pull_request:
# opened: PRが新たに作成された時
# ready_for_review: PRの状態がDraftからOpenに変更された時
types: [opened, ready_for_review]
jobs:
add-assignees:
# Ubuntuの最新バージョンでこのジョブを実行する
runs-on: ubuntu-latest
# GITHUB_TOKENの権限の設定
# このワークフローがPRを操作するのに権限設定が必要
permissions:
pull-requests: write
repository-projects: read
# 何らかのエラーによりジョブが完了しないケースに備えてタイムアウトを設定している
# ※デフォルトの最大実行時間は360分（6時間）とのこと
# NOTE: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes
timeout-minutes: 3
# Dependabotなどのbotではなく、かつ、Assigneesが設定されていない場合にのみこのジョブを実行する
if: endsWith(github.actor, '[bot]') == false && github.event.pull_request.assignee == null
# PRの作成者自身がそのPRのAssigneesに自動割り当てされるようにする
steps:
- name: Auto Assign PR Assignees
env:
GITHUB_TOKEN: ${{ github.token }}
GITHUB_REPOSITORY: ${{ github.repository }}
run: gh pr edit ${{ github.event.number }} --add-assignee ${{ github.actor }}
上記のような auto-assign-pr-assignees.yml ファイルを作成し、これを .github/workflows/ ディレクトリに配置するだけでOKです。
これで PR の作成時にその PR を作成した開発者が自動で Assignees として割り当てられるようになります。
ちなみにこの GitHub Actions の実行時間は数秒程度です。
なのでわざわざ timeout-minutes を設定する必要はほとんどないのですが、今後また別の GitHub Actions を作成するかもしれないことを考えると timeout-minutes の設定をクセづけておいた方がいいと思い、念のため設定しています。
最後に
今回取り組んだ課題はなかなかに地味な内容ですが、こういった取り組みの積み重ねや「小さなことでも改善する」という心がけこそが日々の開発効率を向上させていくのだと信じています！
トラストバンクでは一緒に働く仲間を絶賛募集中です！
ご興味を持たれた方はぜひお気軽にご連絡ください！
参考にした記事・リンク・書籍