GitHub Actionsのcache
GitHub Actionsを普段利用してGoのProjectをメンテナンスしているのですが、
cacheがうまく効いてないような動作が見られたので、原因と改善策をまとめようと思います。
従来のJob
まずはcacheが効いてなかった従来のjobです。
|
|
golangci-lint
を行うlint jobです。
actions/setup-go@v4
から内部でcacheが効くようになったとのことで、もうえーでしょ!と思い、この設定で運用してました。
ただ書いているように、これではcacheがうまく効きません。
効かない理由は以下です。
- GitHub Actions の cache の探し方
- cache の作り方
1. GitHub Actions の cache の探し方
公式document を読むと、cacheの探し方は以下の順番で行われます。
- workflowを実行しているブランチ(例えばPRを上げているブランチなど)
- default ブランチ
- base ブランチ
例えば、workflowの実行を on: pull_request
だけにしているなど、default brnachでCIを回していない場合など、
cache の作り方次第では、1のworkflow実行しているブランチでの初回は必ずcacheが効かない可能性があります。
回避方法として、default/baseブランチで cache が作られるような workflow にすることで大体のケースをカバーできます。
2. cache の作り方
例えば、 actions/setup-go
で作成される cache の primary-key は setup-go-${platform}-${linuxVersion}go-${versionSpec}-${fileHash}
になります。
この方式であれば、ブランチ名なども入っていないので、1のケースだけを実行していればcacheをうまく使ってくれるでしょう。
仮に、 actions/cache
などを使って、cache keyを自身で作成している場合、ブランチ名や、WF実行番号などをkeyにしてしまった場合、
restore-keys
に正しいkeyを指定しないとcache hit しない可能性が出てきます。
今回色々と試行錯誤する中で、このアンチパターンも踏んでしまったので、念の為書いておきます。
最終的なJob
最後に最終的なJobです。
actions/setup-go
の cache は disableにして、従来の actions/cache
を使うことで、cache keyをsimpleにしてメンテナンスをしやすいようにしてみました。
save時のcache keyはdefault ブランチで作成するcache keyとPRブランチで作成するcache keyを別々に作成することにしました。
|
|