actions/setup-goを置き換えてGo CIのテスト実行時間を69%削減
Scaling Golang CI by Replacing actions/setup-go
CloudXはGitHub公式のactions/setup-goを代替するcloudx-io/setup-goをオープンソース化した。公式アクションは並列ジョブが同じキャッシュキーを奪い合い、古いキャッシュを読み続けるため、テストが無駄に再実行される。ジョブ識別子をキーに含め毎回キャッシュを書き込む方式に変えたところ、テストジョブの中央値は131秒から41秒へ短縮。4,000コミットの分析ではテストパッケージ実行の86%が不要だった。
並列lintジョブが共有キャッシュキーの競合に勝ち、テストにとって非常に古いビルドキャッシュ状態を保存してしまう。以降のテスト実行はそのlint向けキャッシュを繰り返し復元することになる。
HNでの議論
19- wannabe44
私はいつもCI用にカスタムビルドしたDockerイメージを使い、セキュリティ修正のために定期的に更新することを推奨している。CIは、開発マシンで同じことを実行する標準時間より数秒以上かかるべきではない。
しかし、周りの人たちは毎回のCI実行でグローバルミラーからapt installやpip installすることを気にしていない。だから私はただの自閉症なのかもしれない。
- lukasschwab
公式ブログ記事には載らなかったけれど、HN読者にとって興味深いかもしれない良いこぼれ話がいくつかある！
ほんの少ししか触れられていないが、キャッシュ・プルーニングの変更は面白かった。キャッシュの蓄積はデフォルトのactions/setup-goでも起きるが、cloudx-io/setup-goではキャッシュ書き込みの回数が劇的に増えたため、実際に問題になった。
キャッシュが大きくなるにつれて、GitHubのactionsキャッシュから読み込む時間も長くなる…そしてそれがCIで無視できない時間の浪費になるまで増え続ける。私たちは基本的なmark-and-sweepでプルーニングしている。
さらに掘り下げると、プラグイン可能な`GOCACHEPROG`（Go 1.24で導入）は本当に便利なツールだ。例えば、計測のために通常のキャッシュロジックをシムで置き換えたりできる。理論的には、これはリモートキャッシュにも魅力的なはずだ。
- peterldowns
みなさん、著者の一人です。これは「小さな」改善ですが、ここ数ヶ月で開発者の時間を大幅に節約してくれました。デフォルトのactions/setup-goが、複数のgolangアクションを同時に実行したい場合に単純にうまく機能しないのは、私には本当にクレイジーに思えます。
ブログ記事には技術的な詳細がたくさんありますが、コードを読んで自分で試すこともできます：