CSS調整

2024年3月15日

GitHub でカスタムフィールド（属性）の代わりになるもの

github の issue や pull request(PR) には所謂カスタムフィールドとか属性とかプロパティとかいうようなものは現状存在しないので、チケットトラッキングシステム的な使い方をしたい場合には、何らかの方法で代替案を見つける必要があります。

ラベルだけでがんばる

issue / PR にも Label は貼ることができるので、 Tracker: Bug, Tracker: Feature Request, Status: Ready, Status: New のようなキーと値がセットになったLabelを全種類用意し、必要なLabelをすべて issue / PR へ設定すれば分別することは可能かと思います。

Label は /issues や /pulls の一覧画面でも表示されるので一覧視認性はそれなりで、検索も可能。

ただし、並び順も管理する必要があるのと、単純に Label 全体の管理が大変だし、 Label の追加や貼り替え（ Status: New を消してから Status: Ready を付ける等）、 特にそれをを手作業でやろうとすると Label 選択のUIの狭さもあってすこぶる面倒というデメリット。
また、固定文字列以外はおよそ設定不可。（例えば、「完了予定日」とか。全日付の Label を用意すればいけるかも）

Project と紐づける

issue / PR だけだと難しいのですが、 project を紐づけることで大体の問題は解決できます。

/issues や /pulls では設定値は確認できないし、検索もできないですが、 project で一覧表示するなら設定値も確認できるし、検索もできます。

デメリットとしては、 project が user または org に横断であるため、複数リポジトリで利用している project で特定リポジトリの issue にだけフィールドを追加したい、といったパターンでは、フィールドを追加すると関係ないリポジトリの issue にもフィールドが増えてしまうという点と、そもそもの話で、 project を紐づけなければいけないという点があります。

特に外部から graphQL なりで issue を作って、 project に紐づけて、かつ特定のフィールドに特定の選択肢を入れるのは慣れるまでは結構面倒かと。

本文に書く

project が活かせそうな環境なら project を使う、がおおよそ最適解だと思いますが、それができない場合。

原初に立ち戻って issue / PR の本文に書いて管理するのはどうだろう、というやり方。

実はこれはソース上ではこうなっています。
タグっぽい文字列はレンダリング時に無視してくれるようなので、これを利用して上記のように記述しておくことで、 /issues や /pulls でも特定フィールドに対する検索を以下のようなワードで行うことができます。
issue template が使えるのと、外部からAPIで更新するときも特定の正規表現に引っ掛けやすいので多少は parse しやすいかも（？）

更新時に本文まるっと更新する必要があるのが微妙、そして一覧での視認性は皆無というデメリット。

ただ、やってることが誰にでもわかりやすい。

まとめ

Project に紐づけられるならそれでいいかと。

特殊なケースにおいては本文を利用する、が使えそう。

ラベルでがんばるのはちとおすすめしがたい。

といった感じでしょうか。
ラベル: