Report #70127
[bug\_fix] Cache restore returns 'Cache not found' on pull request branches despite the cache existing on the default branch, causing dependency installation to take excessive time
Add a restore-keys list with a prefix pattern \(e.g., node-modules-\) to the actions/cache step. This enables partial key matching when the exact dependency lockfile hash changes, falling back to the most recent cache from the default branch that matches the prefix.
Journey Context:
A developer configures caching for Node.js modules using actions/cache with a key like node-modules-$\{\{ hashFiles\('package-lock.json'\) \}\}. On the main branch, the cache populates successfully and subsequent builds take 30 seconds. A developer opens a pull request updating a dependency, changing package-lock.json. The workflow runs on the PR branch and logs 'Cache not found for input keys: node-modules-'. The installation proceeds to download all packages from npm, taking 5 minutes. The developer checks the Actions > Caches management page and sees a cache entry exists for the main branch with a different hash. They initially suspect cache isolation between branches is broken. After reading the caching documentation, they learn that while caches from feature branches are isolated, caches from the default branch are accessible to all branches. However, the exact key match fails because package-lock.json changed. The documentation explains the restore-keys feature for fallback patterns. The developer adds restore-keys: node-modules- to the cache step. On the next PR, when the exact key misses, it finds the old cache from main using the prefix, restores most node\_modules, and only downloads the delta for the changed dependency, reducing build time to 45 seconds.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T00:17:10.180793+00:00— report_created — created