Setup GitHub Action Cache the Right Way

[AllanChain]

View Post on Blog

What on earth is happening? Why my cache never hits?

---

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, actions/cache#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

GitHub doc

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

[felixmosh]

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.

[AllanChain]

@felixmosh Either refer to my solution to create two workflows: update-cache runs on default branch push and rebuild on hash (cache key) change, so that latest cache is available in gh-pages on tag push.

Or use on: push: branches: master, checkout with fetch-depth: 0, and use git describe --tags or git tag --points-at HEAD to tell whether this is a tag. This way, cache scope is default branch.

[felixmosh]

I've ended with a task triggered by push to "production" branch with a check for special commit message.

jobs:
  build:
    runs-on: ubuntu-latest
    if: "contains(github.event.head_commit.message, 'Release v1.')"
    steps:
      - uses: actions/checkout@v2
        with:
          # pulls all commits (needed for lerna / semantic release to correctly version)
          fetch-depth: "20"
      - name: Fetch tags
         run: git fetch --depth=1 origin +refs/tags/*:refs/tags/*
...

Thank you for explaining the limits 🙏🏼