自作ツールの公開ワークフローを整えた
·478 words
🗣️ 背景 # 色々な CLI アプリケーションを作っている。十数個ある。そのリリース作業で、ずっと以下の3つに困っていた。
1. 1回のリリースで触る場所が多い。 昨今の CLI アプリケーションは、バイナリを置いて終わりではない。macOS と Linux、arm64 と amd64 の組み合わせでバイナリを用意し、コンテナイメージを公開し、crates.io などのレジストリに登録し、Homebrew🍺 のレシピを更新し、プロダクトのホームページも作る。1回のリリースに対して、公開先がいくつもある。
2. 同じ情報を何箇所にも手で書き写していた。 バージョン、リリース日、説明、ライセンス。同じ内容を、プロダクトのリポジトリ、Homebrew のレシピ、自分のホームページに、それぞれ別々に書いていた。二重、三重の管理である。当然、情報の齟齬が様々なところで生じるし、更新忘れも結構あった。
3. プロダクトの一覧が、機械可読な形でどこにもない。 どんなプロダクトがあるのか、それぞれいつリリースしたのか。ホームページに載せたくても、プログラムから読める形で集約された場所がないので、結局また手で書くことになる。2の原因でもある。
このうち 1 は、後述するように既存のツールでもそれなりに何とかなる。厄介なのは 2 と 3 で、これは第1次情報がどこにあるのかを決めていないことが原因である。裏を返せば、正となる情報を1箇所に決めて、他はすべてそこから取ってくるようにすればよい。
このようなことを自動化したいなと、これまでずっと思っていたのだが、この度、ようやく目処が立ったので、内容をまとめておく。
🌊 Workflow # 最初に行うべきは、マシンリーダブルなものを第１次情報とすることである。これを tamada/api として作成した。そして、プロダクトの情報は基本的に GitHub で管理し、GitHub 上で管理できない情報のみを tamada/api に置くことにした。加えて、GitHub Pagesで、擬似REST APIとして、さまざまな情報を公開することにした。基本的に情報を取得させるだけであるため、GET メソッドのみ対応として、JSON を様々な場所においておくことで対応した。具体的な内容は、https://tamada.github.io/api/ を参照されたい。ホームページの更新や Homebrew なども、すべてこのリポジトリの GitHub Pages から情報を取得することにする。