How come the actions/cache is failing so much/often?

I use this to cache the ./node_modules/ directory between workflows:

      - name: Cache node_modules
        uses: actions/cache@v2.1.6
        id: cached-node_modules
          path: |
          key: ${{ runner.os }}-${{ hashFiles('yarn.lock') }}-${{ hashFiles('.github/workflows/pr-test.yml') }}

If, between two workflow runs, the runner.os hasn’t changed, the yarn.lock hasn’t changed, and the .github/workflows/pr-test.yml hasn’t changed, why do I get a cold cache on the second workflow?

Here are two workflows that run ~4 hours apart and no other PRs ran within that timespan (I dont’ think)

  1. Radically streamline the PWA landing page · mdn/content@a202109 · GitHub
  2. Reframed sentences · mdn/content@3c1ae8f · GitHub

Because it’s easier see, here are two screenshots of their outputs where I’ve clicked to expand the relevant steps:

First one:

4 hours later

As you can see, the cache key is exactly the same between the two runs


It’s not too large. It’s only 17MB.

It’s definitely not the first time this happened. It happens a lot. Often.
I can understand why you would have a cache miss on the second run, if by some happenstance, the cache server had been cleared which can happen. But why does this happen so often.

Are those workflows on different branches? If yes, that’d explain it (see Restrictions for accessing a cache):

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 main).

No, they’re from different people’s branches from their forks.
But if it could run on main too, we would be able to reuse the cache?!

Our workflow looks like this:


    runs-on: ubuntu-latest

so if I make it so it build on pushes to main too, then all consecutive PRs will be able to re-use the cache. Cool! I’ll try that.

1 Like