actions/cache "Cache not found for input keys" in CI
actions/cache looked up your exact key and then each restore-keys prefix and found no match, so it logs "Cache not found for input keys" and continues with cache-hit set to false. This is a normal cold cache on the first run, but if it repeats every run the key is changing or never gets saved.
What this error means
The Restore step logs "Cache not found for input keys: <key>" and the build redownloads or rebuilds everything. The cache-hit output is false.
Cache not found for input keys: node-cache-Linux-a1b2c3d4e5f6...Common causes
First run, or the key changed since the last save
A key built from hashFiles('**/package-lock.json') changes whenever the lockfile changes, so the new key has no saved entry yet. With no restore-keys, a single byte difference is a full miss.
The cache from a prior run was never saved
If the job that should save the cache failed before the post step ran, or ran on a different branch scope, there is nothing under that key to restore.
How to fix it
Add restore-keys so a near match still restores
- Keep the exact
keyfor an exact hit. - Add one or more
restore-keysprefixes so a previous cache restores on a partial match. - Re-run; on a lockfile change you now restore the closest cache and only fetch the delta.
- uses: actions/cache@v4
with:
path: ~/.npm
key: npm-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
npm-${{ runner.os }}-Confirm the cache is actually being saved
Caches only save when the job reaches the post step. Check that an earlier run logged "Cache saved with key ..." for this key and branch, since caches are scoped to the branch and its base.
How to prevent it
- Always pair
keywithrestore-keysprefixes for graceful partial hits. - Use a stable key prefix plus a hash suffix so most runs land near a prior cache.
- Verify the first successful run reports "Cache saved with key".