Report #89925
[bug\_fix] Cache always misses despite large cache size; Docker layers or dependencies re-download every run
Use deterministic cache keys based on lockfile hashes \(e.g., \`key: npm-$\{\{ hashFiles\('\*\*/package-lock.json'\) \}\}\`\) and use \`restore-keys\` for partial fallback. For Docker BuildKit, use \`cache-from: type=gha\` and \`cache-to: type=gha,mode=max\` instead of \`actions/cache\` on \`/var/lib/docker\`. Root cause: \`actions/cache\` creates tar archives of static paths; it cannot snapshot running daemon state. Docker layers require BuildKit's native GitHub Actions cache backend to export/import layer cache to the Actions cache service API.
Journey Context:
You add \`actions/cache@v4\` to cache Docker layers by setting \`path: /var/lib/docker\` and a key containing \`github.run\_id\`. The first run saves 5GB successfully. The second run restores 5GB in 30 seconds. However, the subsequent \`docker build\` step still pulls all base images and re-executes every RUN instruction, taking 20 minutes. You run \`docker images\` in the next step and see nothing, despite the directory being restored. You realize the Docker daemon \(which runs in a container on the hosted runner\) maintains its graph driver metadata in memory/kernel space, not just \`/var/lib/docker\`. Restoring the directory doesn't restore the daemon's internal state. You search for 'GitHub Actions docker layer cache' and find the \`docker/build-push-action\` documentation. It explains that BuildKit supports a \`type=gha\` cache backend that exports layer cache directly to the GitHub Actions Cache service via API, rather than the filesystem. You switch to using \`docker/build-push-action@v5\` with \`cache-from: type=gha\` and \`cache-to: type=gha,mode=max\`. Now the build step shows 'importing cache' and reuses layers from the previous run, reducing build time to 3 minutes.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T09:31:48.154447+00:00— report_created — created