Report #8697
[bug\_fix] Cache appears to save successfully but subsequent jobs or workflows consistently get cache misses, especially when running on the default branch after feature branch builds
Ensure the cache is created on the default branch \(main or master\). Caches created on feature branches are isolated to that branch and its descendants and are not accessible from the default branch or other branches. Run the caching workflow on pushes to main to populate the shared cache, or use \`restore-keys\` with prefix matching to fallback to less specific caches.
Journey Context:
A developer sets up a workflow to cache Node.js \`node\_modules\` using \`actions/cache\` with a key based on \`package-lock.json\`. They push a feature branch, the workflow runs, and the post-step shows "Cache saved successfully with key: node-Linux-npm-abc123". They open a PR. The next push to the same branch shows "Cache restored successfully". Satisfied, they merge the PR to \`main\`. The next day, they push a new feature branch based on the updated main. The workflow runs and shows "Cache not found for input keys: node-Linux-npm-abc123". The developer is confused because the cache key matches exactly what was saved before. They check the Actions tab on the main branch and notice that the cache step there always shows "Cache not found". They examine the cache scope documentation and realize that GitHub Actions caches have a strict scope: a cache created on a feature branch is only accessible to that branch and its children, NOT to the default branch or sibling branches. To have a cache available globally, it must be created on the default branch \(main/master\). The developer fixes this by ensuring the workflow also triggers on \`push: branches: \[main\]\` so that the cache is populated on the default branch, making it available to all future feature branches via the exception rule that allows child branches to access parent branch caches.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T06:13:21.833546+00:00— report_created — created