actions/cache: same key, cache hit on push but always a miss on pull_request from the same branch

[TorbenGuenther132]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Actions Cache

Discussion Details

Hi all,

I'm probably missing something obvious, but I've been staring at this for a while and can't work it out. I've put together a minimal public repo that reproduces it: https://github.com/TorbenGuenther132/node-cache-demo

I have a Node project with a pretty standard workflow that caches node_modules. It runs on both push and pull_request. Caching works perfectly on push, but every pull_request run reports a cache miss, even though the logs show the exact same cache key in both runs.

The workflow (.github/workflows/ci.yml):

on:
  push:
    branches: ['**']
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - uses: actions/cache@v4
        with:
          path: node_modules
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-
      - run: npm ci
      - run: npm test

What I see:

1. Push to feature/add-ci (run Welcome to GitHub product feedback #1): first run logs a miss, then saves Linux-node-c732972...e19abd at the end. Fine.

2. Second push to the same branch (run Feature Request: Select a column when adding an issue to a project #2): the cache is restored from that same key. So the key is stable and the cache exists.

3. Open a PR from feature/add-ci into main. The pull_request run logs:

   Cache not found for input keys: Linux-node-c732972539db6dedf65c3c09c83c9b0829d1ba93880297b11b97909759e19abd, Linux-node-
   

   Same hash as the push run, character for character. The restore-keys prefix Linux-node- finds nothing either.

So the same commit, same lock file, same key, and the push run hits while the PR run misses.

Things I've already checked:

• The key is identical between push and PR runs (copied from the logs).
• The Caches page (Actions > Caches) shows the entry with the expected key, ~310 KB, and it's listed under feature/add-ci.
• It's not a fork, the PR is from a branch in the same repo.
• Repo is tiny, nowhere near the cache size limit.

The only difference I can spot in the logs is the ref: push runs are on refs/heads/feature/add-ci, and the PR run is on refs/pull/1/merge. I couldn't find anything conclusive in the docs about whether that matters for cache scoping.

Is this expected? If so, what’s the right way to configure it so PR runs actually benefit from the cache? Right now every PR run does a completely cold npm ci, which is exactly what I was trying to avoid. I don’t mind an occasional miss after the lockfile changes, but seeing the cache skipped on every run makes me think the key or restore logic is wrong. Tropical Casino https://tropical-casino.com/ gives me the same reaction when game loading ignores saved session state: technically the flow still works, but you lose the whole advantage of keeping reusable data around. Is there a recommended cache key pattern for this setup?

Thanks in advance.

[muhammad-a-dev]

This is expected cache scoping, not a broken key.

What’s going on

actions/cache scopes entries by ref.

• On push, the cache is saved under the branch ref you pushed (e.g. refs/heads/feature-x).
• On pull_request, the run’s “current branch” for cache is the merge ref refs/pull/<n>/merge — not your head branch.

A pull_request workflow can restore caches from:

1. that merge ref,
2. the base branch,
3. the default branch.

It does not restore caches that only exist on a sibling/head branch from a prior push to feature-x, even if the key string is identical. That’s why you can see a hit on push and a miss on pull_request with the “same” key.

Also: caches created by a pull_request run are scoped to that merge ref and are only useful for re-runs of that same PR — they won’t warm main or other PRs.

Docs: Restrictions for accessing a cache

What to do

1. Warm the cache from a trusted path that PR runs can read — typically a push workflow on the default/base branch (or ensure the cache already exists there).
2. Prefer dependency keys that don’t include the branch name, e.g. ${{ runner.os }}-pip-${{ hashFiles('**/requirements.lock') }}, plus broad restore-keys.
3. For Python, actions/setup-python with cache: pip (or poetry/pipenv) is usually simpler than hand-rolled cache steps.
4. In the PR job log, expand the cache step and confirm which ref/scope it searched; you’ll usually see it miss the head-branch entry.

If you paste your exact key / restore-keys and whether the successful push was to the PR head vs main, we can sanity-check the scope path.

[v-coder247]

Hi @muhammad-a-dev, thanks for participating in GitHub Discussions!

Please note: we’ve clarified our stance on using generative AI tools like ChatGPT within our Community via this announcement. Please review the guidelines to ensure your post meets them as failure to adhere to those rules can result in action taken by our moderator team. 

You can read our updated Code of Conduct and the announcement for more details.

Please feel encouraged to continue engaging in Discussions as your authentic self though. We appreciate you being a part of the Community 🌟

[mohdarshadkhan01]

on:
push:
branches: ['**']
pull_request:

jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- uses: actions/cache@v4
with:
path: node_modules
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-
- run: npm ci
- run: npm test

[muhammad-a-dev]

That YAML is the same shape as the original report, and the key is not the problem. Two things are stacking:

1. Cache scope (the miss)

pull_request runs look up caches from refs/pull/<n>/merge, then the base/default branch — not from refs/heads/feature/add-ci where the push run saved the entry. Identical Linux-node-<hash> keys still miss across those scopes. That’s expected: cache access restrictions.

Warm the cache with a push to main (or whatever the PR targets) so PR jobs can restore from the base/default scope.

2. npm ci after caching node_modules (the restore wouldn’t help anyway)

npm ci removes node_modules and reinstalls. Even on a cache hit, the next step throws the restore away. Caching node_modules then always running npm ci is the wrong pair.

Prefer caching the npm cache and letting setup-node own it:

- uses: actions/setup-node@v4
-   with:
-     node-version: 20
-     cache: npm
- run: npm ci
- - run: npm test
- ```
That caches `~/.npm` keyed off `package-lock.json`. `npm ci` still does a clean install, but downloads stay warm — and it works for both `push` and `pull_request` once a matching cache exists on the base/default branch.

If you really want to skip `npm ci` on a hit, cache `node_modules` **and** gate the install:

```yaml
- uses: actions/cache@v4
-   id: npm-modules
-   with:
-     path: node_modules
-     key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
- if: steps.npm-modules.outputs.cache-hit != 'true'
-   run: npm ci
- ```
…but still warm that key from `main`, or PR runs will keep missing.

@TorbenGuenther132 your logs already show this: push on `refs/heads/feature/add-ci` hits, PR on `refs/pull/1/merge` misses the same key. Merge/push a green CI run to `main` once, then re-run the PR.

[Vishwas-Srivastav]

Hey @TorbenGuenther132

The cache-scope explanation above matches GitHub's documented behavior. A cache created by the push to refs/heads/feature/add-ci isn't available to the PR run because the PR is running against the refs/pull/.../merge ref. The PR can use caches from its base/default branch, but not a sibling/head-branch cache. citeturn0search0

There's also a second issue in the workflow that is easy to miss: you're caching node_modules and then immediately running npm ci. npm ci removes the existing node_modules before installing, so even a successful node_modules cache restore would largely defeat the purpose of that cache.

For npm, I'd use actions/setup-node's built-in caching instead:

- uses: actions/setup-node@v4
  with:
    node-version: 20
    cache: npm

- run: npm ci
- run: npm test

setup-node caches npm's global package cache rather than node_modules, so npm ci can still perform its clean install while avoiding downloading all the packages again. The cache key is based on the lockfile, which is also a better fit for this workflow. citeturn0search1turn0search4

So I think there are actually two separate behaviors here: the PR miss is explained by cache scope, while the current node_modules + npm ci combination would prevent the restored modules from being useful anyway.

[Adiitya09]

The cache key itself looks fine. The main issue is the cache scope: a push run saves the cache under refs/heads/feature/add-ci, while a pull_request run uses refs/pull/<number>/merge. GitHub doesn't treat those as the same cache scope, even when the key is identical.

There’s also another thing worth changing: you’re caching node_modules, but then running npm ci, which removes node_modules before reinstalling. So even if the cache hits, most of the benefit is lost.

For this setup, I'd let setup-node cache npm's package cache instead:

- uses: actions/setup-node@v4
  with:
    node-version: 20
    cache: npm

- run: npm ci
- run: npm test

This keeps npm ci clean while allowing the downloaded npm packages to be reused. A cache populated from the default/base branch can then be restored by PR runs.

So I think there are actually two separate issues here: cache scope explains the miss, while caching node_modules + npm ci explains why the cache wouldn't provide much benefit even after fixing the scope.