🙏

昔作ったGitHubのLabelを供養する

6 min read

はじめに ⚡

昔、あるプロジェクト用にGitHubのLabelをいくつか作成しました。
作ったものの、上手いこと使いこなせてなかったのでこの記事で供養したいと思います。

合掌🙏

クローズドソースな環境で複数人での開発に基づいて書いています
OSSの場合はまた勝手が違ってくると思います
Pull Requestを「PR」、IssueとPRを総称して「チケット」としています

そもそもラベル機能って何? 🧐

IssueやPull Requestを分類するための機能です。
新規Repositoryを作成したらデフォルトで用意されています。
プロジェクトで作成したIssue, PRにラベルを適用することで、
参照時にフィルタリングを行えたりできます。

ラベルの追加、編集、削除はもちろん可能です。
Organizationの場合は、 全Repositoryのdefault Labelを管理することもできます。

GitHubのdefault Labelはこちら

https://docs.github.com/ja/issues/using-labels-and-milestones-to-track-work/managing-labels#about-default-labels

ラベル作る必要ある? 🤔

デフォルトのもので十分だと思います。
またラベルを使わない選択肢もありかもしれません。

本件では「チケット一覧を見やすくする」目的でつくりました。
「そのチケットで何するか、どのくらいの優先度なのか」は一覧で見れたほうが吉ですね(チケットのタイトルの付け方でも補完できますが、、)
私は、新しいプロジェクトに参画するとき、まずIssueやPRを掘ってそのプロジェクトの空気感や仕様を掴んでいくという作業をよくやります。
また、「なんでこんな修正をしたのかを調査する時に過去のIssueを遡る」みたいな作業はどのプロジェクトでもありがちではないでしょうか。
そんなとき、ラベルが少なからず役にたつと思ってます(思ってた)

Labelの紹介 🏷️

当時の体制

開発メンバー:3人
プロジェクトの概要:フロント開発

チケット管理に関するルール

タスク管理は全体をスプレッドシートで管理して、開発タスクはGitHub Issueで運用
Issueテンプレートはfeature用とbugチケットを用意
Issueの起票は開発メンバーなら誰でも可
チケット起票時に対応するラベルをつける

作ったLabel一覧

我ながら可愛いいです

簡単に説明すると、優先度が の三段階。Issueにつける用のLabelです。
その他は対応内容別に色々って感じです。

振り返ってみて

  • 優先度は だけでいいかも
    用意するなら 🔥 emergency とかで。
    というのもチームメンバー全員がタスク全体の優先度を把握しておく必要はないかなと。
    「このタスクは緊急性が高い」というのが一覧で伝われば大丈夫だと思います。

  • 細かく分けすぎたかも
    なるべく意味合いがかぶらないような作りにしたかったんですが
    featurefixが万能すぎ。 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があるので「もし自動化してたら」をやってみます。

以下のアクションを使用します

https://github.com/actions-ecosystem/action-add-labels
https://github.com/actions-ecosystem/action-remove-labels

優先度系のLabelをIssue Close時に外す

個人的にCloseしたらいらない情報だと思うので

labels: に外したいラベルを列挙すればよい
👀 needs review とかも消し忘れ防止のために入れておいてもいいかもしれない

.github/workflows/labels.yml
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で設定できる

.github/ISSUE_TEMPLATE/BUG_REPORT.md
---

name: 🐛 Bug report
about: バグ報告Issue
labels: '🐛 bug'
---

labelsに付与したいラベルを「,」区切りで列挙すればOK

下書きPR作成時に 🚧 wipをつける

Draft PRを開いたとき、 PRをDraftにしたときってイベントに設定する
アクティビティに[opened, converted_to_draft] を使う
Draftかどうかの判定は以下の構文
if: github.event.pull_request.draft == true

.github/workflows/add_wip_label.yml
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] プレフィックスをつける」 とかしてみてもいいかもしれない

Review Request時に👀 needs reviewをつける

Draft以外のPRを開いたとき、Draft解除したときってイベントに設定する。
ready_for_review を使う。

.github/workflows/add_review_label.yml
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を使う

https://github.com/actions/labeler

まずは ワークフローのファイルを定義

.github/workflows/add_pr_labels.yml
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です。
今回は、cidocs で試してみました。

.github/labeler.yml
👷‍♀️ ci:
  - '.github/*.yml'
  - '.github/workflows/**/*'

📝 docs:
  - '**/*.md'

グロブパターンは以下のような記述でも書ける。

📝 docs:
- any: ['**/*.md']

anyの代わりに all も使えて、 allにした場合は変更したファイル全てがグロブパターンにマッチしている必要があります。


できてた。

おわりに 🌻

Github Actions初めてがっつりさわりました。
便利ですね。ただ細かいとこまでやろうとするとワークフローがどんどん増えていきますね。
DXというにはしょぼい内容ですが、この辺触るの地味に好きです。

振り返り記事かつあまりフォーカスの当たらない機能ですが
なにかしら参考になれば幸いです。

😘

Discussion

ログインするとコメントできます