Cache or Artifact? Ask What Happens When the File Is Missing.

The software package has been built and checked. The release is ready to continue, except the deployment job cannot find the package. Someone opens the cache and discovers that the expected files are gone.

Improving cache availability sounds like the repair. In this illustrative GitLab pipeline, the more important mistake happened earlier: the cache became the only handoff of the particular package that passed the checks.

Cache and artifacts both involve files, which can make them seem interchangeable in a configuration. Their difference becomes clearer when the files disappear. Losing a reusable shortcut is not the same as losing the release output the next job was supposed to use. [1][2][3]

Follow the package from build to deployment

Imagine two jobs, Build and Deploy. Build needs third-party libraries, creates a package called checkout-1.4.2.tar.gz, and checks it. Deploy should then receive the checked package from that run. The names and version in this example are fictional.

The libraries can be good cache candidates when the job has a correct way to obtain them without the cache. Restoring them avoids repeated downloading or preparation. If the cache is absent, the build takes the ordinary route and may run more slowly.

The release package has a different job. Deploy relies on the output produced and checked by Build, not just any similarly named archive it can find. A job artifact retains an output and its relationship to the producing job and pipeline. [2][3]

The same directory name cannot establish that relationship. Another eligible cache writer could supply different contents, or a stale cache could match a convenient key without matching the current inputs. A high cache-hit rate tells you that something was restored, not that it was the right thing. [1][3]

Rebuilding can produce a different release object

When Deploy cannot find the package, rebuilding it seems like a helpful fallback. The job continues and the pipeline turns green. But the object now being released may not be the one that passed the earlier checks.

That doesn't make rebuilding inherently wrong. A designed rebuild-and-validation process can be a legitimate delivery arrangement. The problem is silently substituting a new object simply to keep the release moving, without establishing the evidence the release requires.

For this pipeline, I would first give the checked package an explicit handoff from its producer. A durable package repository or another intentional output arrangement may also fit the delivery design. The important relationship is what was built, what was checked, and what Deploy will actually use.

Artifact retention and access remain practical conditions. A required output must remain available long enough for its intended consumer and review, and its contents should be appropriate for that audience. An artifact is not automatically permanent storage or a safe place for secrets. [2]

Two small tests make the distinction visible

Run the build without its reusable cache. If the cache is only a performance optimization, the ordinary path should still produce a correct result. Separately, test reuse with incompatible or stale inputs so a restored directory doesn't quietly determine correctness.

Now remove or expire the required release artifact in a controlled test. Deploy should stop clearly or follow its explicitly designed recovery route. It shouldn't release an unverified substitute and count that as success.

These are different tests because the two files make different promises. One says, “You can avoid repeating this preparation.” The other says, “This is the output produced for the next stage.”

The original deployment might run more often after a cache improvement and still have an unreliable release handoff. Fixing the handoff addresses the responsibility the file was carrying. The cache can then return to its useful job: making a correct pipeline faster, rather than being the only reason it can work at all.