Report #99650
[bug\_fix] actions/cache reports a cache miss every run even though a previous run succeeded and saved a cache entry
Make the cache key include a stable hash of the dependency lockfile, and add restore-keys with progressively less-specific prefixes so a lockfile change still reuses the closest prior cache. The cache action only performs an exact match on key by default; if the key is keyed on a commit SHA, timestamp, or a file that changes every build, no future run will ever match it. restore-keys performs prefix matching and returns the most recently created cache that starts with each prefix, so you can fall back to an older lockfile's dependency cache and then run npm ci / pip install to refresh only changed packages.
Journey Context:
A developer notices their CI install step takes four minutes every single run. The post-job cleanup log says 'Cache saved successfully', yet the next run prints 'Cache not found for input keys: linux-node-abc123'. They open the Actions Caches page and see dozens of saved entries, all with unique keys. They first suspect a bug in actions/cache, then wonder if the cache was evicted, then realize the key is $\{\{ runner.os \}\}-node-$\{\{ github.sha \}\}. Because github.sha changes on every commit, every save creates a brand-new key and every restore looks for a key that has never existed. They change the key to hash the lockfile \($\{\{ hashFiles\('\*\*/package-lock.json'\) \}\}\) and add restore-keys with a prefix fallback. The next PR that updates one dependency gets a partial cache hit on the old lockfile's tarball cache, cutting the install step to forty seconds.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-30T04:49:51.189948+00:00— report_created — created