2023-09-27 - Nix CI と各ツール毎のCIを併用し、全てで Nix shell と同じバージョンを保つ

[kachick]

Nix は便利。Nix の CI も便利。 しかし新興の #226 を使ってすら、早いとは言っても Nix CI は数分かかる。
元々コンパイル時間が長い言語とか、DBとの接続テストが大量にあるとかでCI実行時間自体が長い環境だとこの程度は誤差の範囲なのかもだけれど、RubyやGoの小さなOSSプロジェクトでCIなんて一瞬やろみたいな感覚からするととても長い。
Nix の思想を考えると本当は全部 Nix CIに一本化するのが筋なんだろうけど、一つ typo直した時の dprint や typos による lint が本来の数秒から数分に延びるのは辛すぎて push したくなくなる。
ということで Nix CI を走らせはしつつも単体でバージョン指定したCIも用意して、トリガー分けたり単体CIが通ったら即マージするようにしている。

この時に面倒なのが、その単体CI中でバージョン指定している部分の更新。
常に最新へ上げて行くなら、なんも書かないか renovatebot を導入すれば良い。
しかし Nix shell 内のバージョンに合わせるという Nix が先、君らは後みたいな方向性だと結局手動更新が必要になってしまう。
面倒な事この上ないけど、生活の知恵としてそれらの箇所には特定の文字列でコメントを入れて置いて grep して置換するようにしていた。
でもなー、 Nix Flake 自体は nix flake update --commit-lock-file とか https://github.com/DeterminateSystems/update-flake-lock みたいにさっくり上がるのに他が面倒になられるの凄い嫌だな・・・
ということで、どうせ全箇所にコメント書いてるならそれをそのまま置換定義にしてしまおうと https://github.com/kachick/selfup を作ってみた。CI内で走らせて https://github.com/kachick/action-typescript-template/pull/427/files こんな感じのPRを自動生成している。便利

ちなみにツールのバージョンを先行させて、そこに適した nixpkgs を使うみたいなのが devbox なのかなーと想像しているんだけど、どうなんだろ？
flake が諸々便利なので devbox は特に試していないんだけど、先にツールバージョンから始まるスタイルだとこの手の話や周辺ツールとの親和性が高そうなのはなんとなく想像できる。