Dependency caches are keyed on the lockfile
A cache key that ignores the lockfile serves stale dependencies after an upgrade, so CI tests a dependency set nobody has. A key that changes on every run caches nothing and pays the restore cost anyway.
Observable check
every dependency cache in the CI configuration caches only reusable package-manager data, derives its primary key from the lockfile, and separates every operating system, architecture, runtime, or package-manager boundary that makes the cached contents incompatible. Any fallback key preserves those compatibility boundaries. A CI configuration that defines no dependency cache falls outside this rule rather than satisfying it with nothing to check.
Where this comes from
- https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching
- https://docs.github.com/en/actions/concepts/workflows-and-actions/dependency-caching
Last read against these sources on 2026-07-28.
The path this rule used to cite, /actions/how-tos/write-workflows/choose-what-workflows-do/cache-dependencies, is a hard 404 with no redirect. The canonical reference is now /actions/reference/workflows-and-actions/dependency-caching, H1 'Dependency caching reference'. It documents mechanism only. The rationale lives on the sibling concepts page, and even there it is conditional selection guidance, 'Use caching when you want to reuse files that don't change often between workflow runs', not a mandate. So the source gives the check its syntax and does not argue that a workflow must cache.