How Does Caching Work in a CI/CD Pipeline?
Learn how CI/CD pipeline caching speeds up builds — cache keys, restore-keys, and Docker layer caching, with correctness tradeoffs explained.
Expected Interview Answer
CI/CD pipeline caching stores the outputs of expensive, repeatable steps — downloaded dependencies, compiled build artifacts, Docker image layers — keyed by a fingerprint of their inputs, so subsequent pipeline runs can restore that output instead of recomputing it, cutting build time significantly.
The most common pattern is dependency caching: a hash of the lockfile (package-lock.json, requirements.txt, go.sum) becomes the cache key, and if that hash matches a previous run, the pipeline restores the node_modules or vendor directory instead of re-downloading everything from the registry. Build-output caching works similarly for compiled artifacts, and Docker layer caching reuses unchanged image layers (using --cache-from or BuildKit's inline cache) so only layers whose upstream instructions changed get rebuilt. A well-designed cache key must invalidate correctly — too broad a key returns stale dependencies after a real change; too narrow a key never hits and provides no speedup — so most pipelines use a primary key that must match exactly plus one or more restore-keys (fallback prefixes) that allow a partial, still-useful cache hit even when the exact key is missing. Caching is a tradeoff: it speeds up pipelines dramatically but introduces a class of bugs where stale or corrupted cache data causes builds to succeed with outdated dependencies, which is why cache keys should be tied tightly to actual inputs and caches should have a sane eviction/expiry policy.
- Dramatically reduces dependency install and build time
- Docker layer caching avoids rebuilding unchanged image layers
- Restore-keys give partial cache hits even on a cache miss
- Frees CI minutes/cost by avoiding redundant work
AI Mentor Explanation
Pipeline caching is like a groundskeeper reusing a pitch report from yesterday if the weather conditions match exactly, instead of re-testing soil moisture and bounce from scratch every single morning. If conditions changed even slightly, the old report is invalid and a fresh test is needed, but a report from a similar recent day can still give a useful starting estimate rather than starting completely blind. This saves hours of prep time every match day when conditions genuinely have not changed. Relying on a stale report when conditions actually shifted, though, can mislead the whole team's strategy.
Step-by-Step Explanation
Step 1
Compute a cache key
Hash the lockfile or other input files that determine the cache contents (e.g. hashFiles("package-lock.json")).
Step 2
Restore on cache hit
If a cache entry matches the key, restore it (node_modules, vendor, image layers) instead of recomputing.
Step 3
Fall back with restore-keys
On an exact miss, use a prefix restore-key to pull the closest previous cache as a partial speedup.
Step 4
Save the updated cache
After the step runs, save the fresh output under the new key so future runs with the same inputs get a hit.
What Interviewer Expects
- Understanding of cache keys derived from input hashes (lockfiles, Dockerfile instructions)
- Awareness of the correctness tradeoff: too broad a key causes staleness, too narrow gets no hits
- Knowledge of Docker layer caching and instruction ordering for cache efficiency
- Familiarity with restore-keys/fallback caching for partial hits
Common Mistakes
- Using a cache key that never changes, serving stale dependencies indefinitely
- Caching build outputs without any invalidation strategy
- Not ordering Dockerfile instructions to maximize layer cache reuse
- Ignoring cache size growth, leading to slow cache restore/save times over time
Best Answer (HR Friendly)
“Caching in a pipeline means we save the results of expensive steps — like downloading dependencies or building Docker layers — keyed to exactly what produced them, so if nothing relevant changed, we restore that result instead of redoing the work. This cuts our build times significantly, but we have to be careful that the cache key really does reflect what changed, otherwise we risk shipping something built from stale, cached dependencies.”
Code Example
steps:
- uses: actions/checkout@v4
- uses: actions/cache@v4
with:
path: ~/.npm
key: npm-${{ runner.os }}-${{ hashFiles("package-lock.json") }}
restore-keys: |
npm-${{ runner.os }}-
- run: npm ci
- run: npm run build
# Docker layer caching with BuildKit inline cache
# docker build --cache-from myapp:latest --build-arg BUILDKIT_INLINE_CACHE=1 -t myapp:latest .Follow-up Questions
- How would you design a cache key that avoids both stale hits and cache misses?
- How does Docker layer caching interact with instruction ordering in a Dockerfile?
- What is the purpose of a restore-key fallback in cache configuration?
- How would you debug a build that passed locally but failed in CI due to a stale cache?
MCQ Practice
1. What should a dependency cache key typically be derived from?
Hashing the lockfile ties the cache key to the exact dependency versions, so it changes only when dependencies actually change.
2. What is the risk of using a cache key that is too broad (rarely changes)?
A key that does not reflect real input changes can cause the pipeline to reuse outdated cached data even after a relevant change.
3. What do restore-keys provide in cache configuration?
Restore-keys let the pipeline fall back to the closest previous cache by prefix match, still saving time even on an exact-key miss.
Flash Cards
What is a CI/CD cache key usually based on? — A hash of input files like a lockfile, so it changes only when dependencies change.
What is a restore-key? — A fallback prefix key that finds the closest previous cache when the exact key misses.
What speeds up Docker builds via caching? — Reusing unchanged image layers via --cache-from or BuildKit inline cache.
Main risk of pipeline caching? — A stale or too-broad cache key can serve outdated dependencies silently.