github actionsのsetup-goのキャッシュは無効にした方がいいかもしれない

雑にまとめます。

• github actionsのsetup-goを使うと、簡単にgoの環境構築ができます。
• 最近v4がリリースされ、cache機構がデフォルトで有効化されました。
• ただ、このキャッシュ機能、基本的に1つのkeyで管理されており、複数のjobでsetup-goを呼び出すと、キャッシュは共有されてる感じになります。
  • 正確にはキャッシュキーは setup-go-${platform}-go-${versionSpec}-${fileHash} で作られるので、platform(linuxとかmacとか)かversionSpec(goのバージョン)かgo.sumのハッシュが違えば別のキャッシュになります。
• setup-goを使った二つのjob、jobA(重い)とjobB(軽い)を用意します。
• 基本的な動作として、先に終わった方のキャッシュが作られると、後から同じキーで作ろうとしても、すでにあるので、キャッシュを作るところをスキップします。
• つまり、jobBのキャッシュが残ります。
• 次に走る時、jobAはjobBのキャッシュを使い、jobBはjobBのキャッシュを使います。
• jobAではプロダクトのbuild、jobBでは簡単なgoで書かれたツールを使いたいと思って、go installして実行するだけのjobだったとして、キャッシュされた結果、簡単なgoで書かれたツールのインストールが少し早くなるだけで、肝心のプロダクトのbuild(go getやコンパイル)は毎回0からやる羽目になります。
• 公式としてはその問題には対処する気はないようです。
  • キャッシュ機能に複雑なものを、goの環境構築ツールに入れたくない、と言うのは、見ている領域が違うのでめちゃくちゃわかる。
• 結論としては、一つのsetup-goしかしない、簡単なワークフローであれば標準のキャッシュを用いても良いが、二箇所以上でsetup-goを呼び出していて、かつそれらが全て同じキャッシュでもいい(どのjobでも毎回最初にgo buildしてる、とか？)という感じでもなければ、setup-goのキャッシュをオフにして、自分でキャッシュ管理をした方が良さそう、と言う感じです。
  • キャッシュをする対象としては、公式が参考になるかもです。
  • linuxで言えば、以下
    • ~/go/pkg/mod
    • ~/.cache/go-build
  • actions/cache@v3を使って、キーは適当に設定してください。
• ちなみにsetup-nodeも同じような感じだったので、同じように複数箇所で呼び出しているのであれば、自分たちでキャッシュ管理をした方が良さそうです。
• なんか勘違いしてるかもなので、コメントでの指摘とかあればお待ちしております。