In a CI pipeline, what is the difference between a cache and a build artifact, and why must a job still succeed when the cache is empty?

## Two mechanisms that look identical Every CI platform offers two ways to move files out of one run and into another, and they are constantly confused because the mechanics are the same: a directory is archived, uploaded to central storage, and restored later. The difference is not in how they work but in what each one promises. A **cache** is a best-effort copy of data the job could produce again on its own. Typical contents: a dependency download directory (`~/.m2`, `~/.gradle/caches`, the npm cache under `~/.npm`, the pip wheel cache, the Go module cache), a package manager's content-addressed store, or an incremental build directory. Nothing about the pipeline's meaning depends on it. The platform may evict it whenever it likes — most impose a total size cap with least-recently-used eviction, plus a retention window measured in days, and caches tied to a branch usually vanish when the branch is deleted. An **artifact** is a declared output of the job. The compiled jar or binary, the test report the pipeline summary renders, the coverage file, the container image reference that a deploy stage will promote. Something downstream — another job, a release page, a human — consumes it, so if it is missing the pipeline is broken. ## Correctness is the dividing line The useful way to hold the distinction is by what happens on absence: - Cache absent → the job does more work and takes longer. Same result. - Artifact absent → the consuming job cannot run. Failure. That is why a cache must never be load-bearing. Concretely, a cold cache is not an exceptional condition to be handled; it is the normal state on a brand new branch, on the first run after an eviction, after a key change, and on any fresh ephemeral runner whose local disk starts empty. Caches also race: two jobs starting at the same time both miss, both compute, and both try to store — so a design that assumes "the previous job populated it" is already wrong. ## The classic mistake The most common cache defect in real pipelines is using a cache as an installer: ```bash # WRONG: the cache is the only thing that puts dependencies on disk if [ ! -d node_modules ]; then npm ci; fi ``` This has two failure modes at once. Cold, the directory is missing and, in the variants that omit the fallback entirely, the build simply fails. Warm, the job runs whatever an older commit's install produced, so dependencies drift away from the lockfile silently — nothing in the diff shows it, and the version that ships is not the version the lockfile describes. The correct shape always runs the real install and lets the cache make it fast: ```bash # RIGHT: install always runs; the cache only saves network and unpack time npm ci # succeeds cold (slow) and warm (fast), with the same result ``` Most package managers are built for exactly this: they read a lockfile, check what is already present in their local store, and fetch only the difference. Cache the *store*, not the resolved tree, whenever the tool gives you that choice. ## What goes where Cache: dependency downloads and package-manager stores, compiled third-party sources, prebuilt fixtures, incremental compilation directories (only when the key genuinely covers every input). Artifact: the build output that will be deployed or published, test and coverage reports, generated SBOMs, logs worth keeping, anything a later stage must consume. When the same bytes need to reach a deploy stage, that is an artifact hand-off, not a cache lookup — the deploy must not depend on a best-effort store. ## Proving cold-cache correctness Because the failure is silent, teams verify it on a schedule rather than by inspection: run the pipeline periodically with caching disabled, on a timer rather than on every push. If the cold run fails, or produces output that differs from the warm run, the cache was hiding a defect that would eventually ship — usually a dependency that no longer resolves, a tool that is no longer installed, or a generated file nobody regenerates any more. A last note worth saying out loud in an interview: a cache is not a security boundary and not durable storage. Anything you would be unhappy to lose, or unhappy for another job to read, does not belong in it.