To be clear, I am talking about https://github.com/actions/cache. Better to have a look at the doc first.
What should be hashed? #
Make sure the file to hash does not always change on every build. After all, you want the cache hit in some cases.
For example, the project is written in JavaScript and uses npm as package manager. You decided to run GitHub Actions to release the package every time you push a tag. And you choose to hash package-lock.json
... Sorry, never hits. Cache is completely useless. That's because the version always changes, even thought the dependencies doesn't, which is what you mean.
Instead, hash rest of the file, use tail -n +4
for example.
Know what you are hashing #
Why? Don't I know what I am hashing?
Maybe, when using glob.
Cache action evaluates hash twice, which can cause problems with glob. For example, https://github.com/actions/cache/issues/344
hashFiles('**/yarn.lock')
is wrong cause it picks yarn.lock files from node_module (as part of the key) at the end of the build, but tries to restore with empty node_modules which produced different hash.
Be careful with cache scope #
A workflow can access and restore a cache created in the current branch, the base branch (including base branches of forked repositories), or the default branch (usually master)
Caches between two parallel branches are not shared. And tags only have access to caches created in default branch. If you want to share cache between build on tags, you would like to keep cache in master scope. For example, use a update-cache.yml
action to keep track of cache.
My Solution #
Checkout https://github.com/AllanChain/webnav/tree/3ddd12f707fc374f907f5a2ac26aaf98a7c9a3d2/.github/workflows
Thank you for clarifying this issue.
Quick question, If I need to cache a build result (Next'js cache). I'm building my app using tags pushes.