0 GitHub Projectsにおける チケットの ステータス更新⾃動化について 2024-07-26 第100回NearMe技術勉強会 YO

1 目次 ● Projectsでのチケット管理 ● Projectsの機能を使って行える自動化 ● Actionsを使わないとできない自動化 ● ワークフローを作ってみて

2 要約 ● GitHub Projects (V2)で複数のRepositoryのチケットを管理する ● チケットのステータス更新を自動化したい ● ステータス更新自動化の際、UI上で完結するもの（Projectsの workflow）と、ワークフローの設定を記述しないといけないもの （GitHub Actions）がある ● Personal Access Tokenの設定方法については割愛する

3 Projectsでのチケット管理 理想の運用 ● マネージャーから見てチケットのステータス、各人の業務量が分かる状態 ● 開発者は事務的な作業を頑張らなくてもよい状態 自動化の背景 ● 「どの人がどんなタスクを持っている」のか都度コミュニケーションが発生してしまう ● 開発者がチケットのステータス更新を忘れてしまうことで、マネージャーはリ アルタイムなチケットの進捗が分からない ● （今後）チケット更新がリアルタイムで行われないと、チケットを消化するのに 要した実測値が正しくとれない

4 Projectsでのチケット管理 Projectとは？ ● UserまたはOrganizationに紐づく機能 ● 複数のRepositoryのIssueを一覧化したりIssueをボードに並べることが できる（ソート、フィルター、グルーピング） なぜGitHub Projects？ ● マネージャーは複数のリポジトリのチケットを一元的に管理したい ● 開発者側の既存の運用をなるべく変えたくない（GitHubのIssueで開発 のチケットを管理、チケット管理のためにツールを増やしたくない）

5 Projectsの機能を使って行える自動化 今回の説明で使用するProject ● スタータスは以下の5つ ○ 📪とりあえず ○ 📚着手前 ○ ⌨開発中 ○ 👀レビュー中 ○ ✅マージ済み

6 Projectsの機能を使って行える自動化 トリガー アクション Repositoryに新しいIssueが追加 Projectsに追加する Issueに紐づいたPull Requestが マージされた Issueのステータスを「✅マージ済 み」にする Issueのステータスが「✅マージ済 み」になった Issueをクローズする

7 Actionsを使わないとできない自動化 Actionsとは？ ● Repositoryに紐づく機能 ● Repository内での操作を自動化できる

8 Actionsを使わないとできない自動化 トリガー アクション IssueにDraft PRが追加 Issueのステータスを「⌨開発中」にす る IssueにPRが追加 Issueのステータスを「👀レビュー中」 にする Issueに追加されたDraft PRがPRに変更 された 「⌨開発中」から「👀レビュー中」に移動 する Issueに追加されたPRがDraft PRに変更 された 「👀レビュー中」から「⌨開発中」に移動 する Issueにassigneeが追加 「📪とりあえず」から「📚着手前」に移動 する

9 Actionsを使わないとできない自動化 ①起案 ②棚卸 ③実装はされたが 承認はまだのもの ここの自動化 ● 「実装が作られた」を感知 ● Project上でチケットを移動 ④承認

10 Actionsを使わないとできない自動化 1. 開発者がPull Requestを作成する（トリガー 1） 2. GitHub ActionsがPull Requestの説明を読んで、メンションさ れたIssueに作成されたPull Requestの種類に応じたコメント を書きに行く（トリガー 2） 3. GitHub ActionsがIssueにコメントされたのを感知して、コメン ト内容に応じてProject上でIssueを移動 ● Issueにコメントが記載 される ● PR作成 ● Draft PR作成 ● Draft PR→PR ● 閉じられてたPR再開 YO YO

11 Actionsを使わないとできない自動化 作成したワークフロー ● キーワード ○ Expressions : ${{ }}を使うことで環境変数などをワークフロー内に埋め込める 機能 ○ Contexts : トリガーやジョブに関する情報にアクセスするための機能 ○ GitHub CLI : GitHubを使用するためのコマンドラインツール ● 以下のGistのコードで解説 https://gist.github.com/yutaokamoto/1bd9bffc70319fb09db256b7e193658c

12 ワークフローを作ってみて 苦労した点 ● GitHub Actionsに慣れること ○ Expressions ○ Contexts ○ GitHub CLI ● GitHub Projects (Classic)だとコメントを記載するのが簡単にできるっぽ い ● Issueに関するワークフローはメインのブランチにマージされないと実行 されない ● Actionが書き込んだコメントに改行が入ってしまう

13 ワークフローを作ってみて 苦労した点 ● GitHub上で自動化の実行を行ってみないと分からないことも多く、デ バッグがやりづらかった ○ debug loggingというログを詳し目に出してくれる機能に途中で気づいた

14 Thank you