やんないほうがいいかも、GitHub Actions の setup-xxx での依存キャッシュ保存 - 誰かの役に立てばいいブログ

GitHub Actions で CI している皆様、こんにちは。 GitHub Actions 便利ですよね。使わない日がないというくらい毎日お世話になっています。 さて、CI といえば良く問題になるのが実行時間。 長い待ち時間は開発効率を下げますし、プライベートリポジトリだと Runner の費用も嵩んでしまいます。 時間を短縮する方法は色々ありますが、一手目によく行われるのが依存パッケージのキャッシュじゃないかなと思います。 例えば Go で開発していると、依存パッケージは ~/go/pkg/mod にダウンロードして保存されます。 これを CI 実行のたびにダウンロードしてコンパイルするのは時間とお金の無駄というものです。 幸い、GitHub Actions には CI の実行間でこういった依存パッケージを保存して再利用できるキャッシュ機能があります。 詳しくは以下のドキュメントを

[Kesin]

大規模なリポジトリになると主にこの挙動が原因で10GBを超過してキャッシュを有効活用できてない事例を何度か見たことがあるので、CIが何か遅いと思ったらまずキャッシュ容量を疑うようになりました

[eichisanden]

これブランチごとじゃなくて依存関係変わらなければキャッシュ使ってよ、といつも思う。

[perl-o-pal]

えっ、これやらかしてそうな気がするわ。あとで見直さないと。

[omron]

“なんとキャッシュはブランチ毎に名前空間が分かれて保存されるという仕様でした”

[syu-m-5151]

とても、良い記事だ…知見にもなるし教訓もある。

[inouetakuya]

まあよしなにやってくれるんだろうと思って、わたしもきちんと調べていなかったので有り難い記事でした。感謝

[akymrk]

“なんとキャッシュはブランチ毎に名前空間が分かれて保存されるという仕様でした”

[issyurn]

“なんとキャッシュはブランチ毎に名前空間が分かれて保存されるという仕様でした。” デプロイ専用のブランチで使用するのが良さそう

[Nyoho]

GitHub Actionsのキャッシュのこと全然知らなかった。

[atsushieno]

ブランチが変わるとそもそもCIに使われているVM設定が違う可能性があるし、異なるVM間で問題なくactions cacheを復元・利用できるかは怪しいので、ブランチごとに保存される設計なのはまあ安全に倒していて妥当という印象

[gfx]

これは罠…。

[inductor]

いい指摘

[yfukuda827]

知らなかった

[lepton9]

“。”

[mizdra]

なるほど