昔作ったGitHubのLabelを供養する
はじめに ⚡
昔、あるプロジェクト用にGitHubのLabelをいくつか作成しました。
作ったものの、上手いこと使いこなせてなかったのでこの記事で供養したいと思います。
合掌🙏
そもそもラベル機能って何? 🧐
IssueやPull Requestを分類するための機能です。
新規Repositoryを作成したらデフォルトで用意されています。
プロジェクトで作成したIssue, PRにラベルを適用することで、
参照時にフィルタリングを行えたりできます。
ラベルの追加、編集、削除はもちろん可能です。
Organizationの場合は、 全Repositoryのdefault Labelを管理することもできます。
GitHubのdefault Labelはこちら
ラベル作る必要ある? 🤔
デフォルトのもので十分だと思います。
またラベルを使わない選択肢もありかもしれません。
本件では「チケット一覧を見やすくする」目的でつくりました。
「そのチケットで何するか、どのくらいの優先度なのか」は一覧で見れたほうが吉ですね(チケットのタイトルの付け方でも補完できますが、、)
私は、新しいプロジェクトに参画するとき、まずIssueやPRを掘ってそのプロジェクトの空気感や仕様を掴んでいくという作業をよくやります。
また、「なんでこんな修正をしたのか
を調査する時に過去のIssueを遡る」みたいな作業はどのプロジェクトでもありがちではないでしょうか。
そんなとき、ラベルが少なからず役にたつと思ってます(思ってた)
Labelの紹介 🏷️
当時の体制
開発メンバー:3人
プロジェクトの概要:フロント開発
チケット管理に関するルール
タスク管理は全体をスプレッドシートで管理して、開発タスクはGitHub Issueで運用
Issueテンプレートはfeature用とbugチケットを用意
Issueの起票は開発メンバーなら誰でも可
チケット起票時に対応するラベルをつける
作ったLabel一覧
我ながら可愛いいです
簡単に説明すると、優先度が 高
、中
、低
の三段階。Issueにつける用のLabelです。
その他は対応内容別に色々って感じです。
振り返ってみて
-
優先度は
高
だけでいいかも
用意するなら🔥 emergency
とかで。
というのもチームメンバー全員がタスク全体の優先度を把握しておく必要はないかなと。
「このタスクは緊急性が高い」というのが一覧で伝われば大丈夫だと思います。 -
細かく分けすぎたかも
なるべく意味合いがかぶらないような作りにしたかったんですが
feature
とfix
が万能すぎ。bug
があればfix
はいらないのでは?。等
タスクの粒度次第だけど、一つのチケットにつけるラベルは2,3個までがmaxかなと思ってます。
それ以上になると逆に見づらい。 -
👀 needs review
の使い所
少人数なのでチャットで「これのレビューお願い」で完結する
あと地味につけ外しがめんどくさい。
他にも消費期限の短いラベル(🚧 wip
とか)はなくても困らないかも。 -
使わないやつも多かった
タスクの内容系のラベル
🎨 accessibility
とか⬆️ update dependencies
とか🐎 performance
とか🌎 i18n
フロントサイドの開発なので、大体UI周り触る。
あとはタスクがそもそもそんなにない → 起票時につけわすれる 😇
あったほうがよかったかもなLabel
「対応しない系」のLabelはあったほうがいいですね。
👯♂️ duplicate
と 🚫 invalid
、あと🔒 not compatible
とか。
Issueをたてたけど、対応せずに閉じる。ということはありがち。
うまく運用できなかったわけ
-
そもそも運用方針をきちんと決めて共有できてなかった
本末転倒ですがこれにつきます😇 -
ラベルつけるのがめんどくさい
つけ忘れもあるし、このタスクはなんのラベル?って考える時間が無駄 -
少人数なプロジェクトだとそこまでこだわらなくてもいいかも
本末転倒2。 これを言っちゃおしまい
その代わりIssueテンプレートやPRテンプレートは使いやすい&手間が少ないものを用意しておいたほうが吉
Label管理を楽にしてみよう 👻
ラベルの付与/外すをポチポチするの意外とめんどいですよね。
当時と違ってGitHub Actionsがあるので「もし自動化してたら」をやってみます。
以下のアクションを使用します
優先度系のLabelをIssue Close時に外す
個人的にCloseしたらいらない情報だと思うので
labels:
に外したいラベルを列挙すればよい
👀 needs review
とかも消し忘れ防止のために入れておいてもいいかもしれない
name: "Remove Priority Label"
on:
issues:
types: [closed]
jobs:
remove_priority_labels:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions-ecosystem/action-remove-labels@v1
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
labels: |
🔥 優先度:高
⚠️ 優先度:中
🍵 優先度: 低
Issueテンプレートによって、ラベルを自動でつける
Bug用のテンプレートでIssueを立てたら 🐛 bug
を付与する。みたいなこと
これは Issue Templateで設定できる
---
name: 🐛 Bug report
about: バグ報告Issue
labels: '🐛 bug'
---
labels
に付与したいラベルを「,」区切りで列挙すればOK
🚧 wip
をつける
下書きPR作成時に Draft PRを開いたとき、 PRをDraftにしたときってイベントに設定する
アクティビティに[opened
, converted_to_draft
] を使う
Draftかどうかの判定は以下の構文
if: github.event.pull_request.draft == true
name: "Add WIP Label"
on:
pull_request:
types: [opened, converted_to_draft]
jobs:
add_wip_label:
if: github.event.pull_request.draft == true
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions-ecosystem/action-add-labels@v1
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
labels: |
🚧 wip
Titleを操作して「[WIP] プレフィックスをつける」
とかしてみてもいいかもしれない
👀 needs review
をつける
Review Request時にDraft以外のPRを開いたとき、Draft解除したときってイベントに設定する。
ready_for_review
を使う。
name: "Add Review Label"
on:
pull_request:
types: [opened, ready_for_review]
jobs:
add_review_label:
if: github.event.pull_request.draft != true
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions-ecosystem/action-remove-labels@v1
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
labels: |
🚧 wip
- uses: actions-ecosystem/action-add-labels@v1
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
labels: |
👀 needs review
余談ですが、 review_requested
ってアクティビティがあるのでそっちのほう適しているかも。
このワークフローのイベントだと「レビュワーを自動アサインする」みたいなjobを入れておくと便利ですね。
変更されたソースの種類によってPRにLabelを自動で付与する
labelerっていうイカしたActionを使う
まずは ワークフローのファイルを定義
name: "Pull Request Labeler"
on:
pull_request:
types: [opened]
jobs:
triage:
runs-on: ubuntu-latest
steps:
- uses: actions/labeler@v3
with:
repo-token: "${{ secrets.GITHUB_TOKEN }}"
sync-labels: true
次にlablerアクション用のファイル .github/labeler.yml
を作成します。
付与したいラベルと、変更ファイルのグロブパターンを記述すればOKです。
今回は、ci
と docs
で試してみました。
👷♀️ ci:
- '.github/*.yml'
- '.github/workflows/**/*'
📝 docs:
- '**/*.md'
グロブパターンは以下のような記述でも書ける。
📝 docs:
- any: ['**/*.md']
any
の代わりに all
も使えて、 all
にした場合は変更したファイル全てがグロブパターンにマッチしている必要があります。
できてた。
おわりに 🌻
Github Actions初めてがっつりさわりました。
便利ですね。ただ細かいとこまでやろうとするとワークフローがどんどん増えていきますね。
DXというにはしょぼい内容ですが、この辺触るの地味に好きです。
振り返り記事かつあまりフォーカスの当たらない機能ですが
なにかしら参考になれば幸いです。
😘
Discussion