pullしたとき、formatをかけ忘れたものが紛れ込んで降ってきて、手元で差分が出て嫌な気持ちになったりした経験、ありませんか？
開発してcommitしてpushしたあとで、formatをかけ忘れていたことに気づいた経験はありませんか？
新しい開発環境で、pre-commitを入れ忘れる人が、一人もいないと言い切れますか？
「formatがかかってないものはマージできないようにしよう！」
そのあと、"fix fmt"なんてcommit messageでpushしたりしてませんか？
その仕事、本当にあなたがやるべき仕事ですか？
(書いててグサグサ自分に刺さる・・・)
CIでできる仕事はCIに任せましょう！
GitHubActionsについて
GitHubが提供する、公開リポジトリなら無料のCIです。
インフラを用意する必要もなく、アカウント登録もGitHubなので必要ないです。
(GitHubのアカウントの登録はもちろん必要です)
CIの管理もGit上でやります。
(ブランチ戦略によっては合わないかもしれない？)
大きなメリットとして、GITHUB_TOKENという、pushしたりPRを作ったりできる権限を持った、GitHubが管理しているTOKENを使えます。
リポジトリを見れたりPRを触れる権限を持ったTOKENの管理って、考えなきゃいけないことも多くて結構大変ですが、全てやってくれるので安心です。
やったこと
やりたいこと
- formatが間違ってるコードがPRになっていたら、formatを直すPRを作る
- 開発者は、作られたPRのマージボタンを押すだけで、formatが正しく直る
できたもの
こんな感じで、自動でPRを作ってくれて、開発者はマージするだけでいいシステム。
ソースコード
いろいろやってるので、少々わかりにくいですが、やってることをまとめると、
といった感じです。
(commit hashを執筆時点のコードで固定化してますが、最新はもっといろいろやってるかもしれません)
起こった(起こりかけた)問題と解決
PRが大量にできてしまうので、force pushして無理矢理消す
PushのたびにformatしてPRを作っていると、一つのPRにいくつものformat修正のPRができてしまいます。
そこで、同じブランチには一つのformatするbranchしか作らないようにして、そこにforce pushすることで、常にPRは一つになるようにしています。
手元でformatをかけると、PRが残ってしまう
いくらformatの指摘を自動でしてくれるとはいえ、指摘を読む前に手元で直してしまうこともあります。
その際はPRをCloseすることにしています。
意図しないPRまで消される
上記PRを消してくれる機能ですが、バグっていて、全然関係ないPRもCloseされてしまう事故が発生しました。
GITHUB_TOKENでPRを作るなどの作業をした場合、user_idとしては 41898282 の固定値になるみたいなので、この値を判定に用いました。
formatterがバグったらどうする？
formatterがバグってて、意図しない変更まで入れてくる可能性があります。
なのでPRという形で、自動で作られたPRも一度目を通すことを推奨しています。
(もうちょっと実績を積んで、任せられるってなったら、自動マージもしてしまえるかもしれませんね)
未解決の問題
FORK先からのPRでは動かない
GITHUB_TOKENはFORK先からのPRでは書き込み権限がありません。
https://github.community/t/optional-read-write-permission-for-forked-repos/16330/2
なので直接pushしてブランチを作ってもらうことで、一旦の解決としています。
別でTOKENを発行したりすればできるかもしれませんが、無用なリスクを負う必要はないと考えています。
終わりに
優秀な開発者の鳩さん@massongitとこのツールを作る機会を作ってくれたなっかあちゃん@nakkaaに感謝します。
自動チェックで単純な指摘をする仕事から解放されたあとは、自動fixで単純な直せるものは勝手に直してくれる世界が来ると信じています。