What is the difference between an artifact and a cache?

A cache is an optimisation: it may be missing and the build still succeeds, just slower. An artifact is an output: something downstream depends on it, or a person will open it. CI systems bill and expire them differently.

How long do build artifacts last?

Not forever. GitHub Actions defaults to 90 days, GitLab to 30, CircleCI to 30, and Jenkins to whatever the job's build discarder says — often a build count rather than an age. Every one of those links eventually 404s.

Should HTML reports be stored as build artifacts?

For machine consumption, yes. For a document a person is meant to read and cite later, no — an artifact link carries an expiry date set by someone else's storage policy, and most CI systems serve the artifact as a zip download rather than a rendered page.

Build artifact

A build artifact is a file or directory produced by a CI job and stored by the CI system for later retrieval — by a downstream job, or by a person clicking through the build UI. Compiled binaries, packaged installers, SBOMs, test result XML, coverage data and generated HTML reports are all routinely stored this way.

Artifact, cache, or package

The three get conflated, and the distinction decides how each is billed and expired:

Kind	Missing means	Lifetime
Cache	Slower build, same result	Evicted by size or idle time
Artifact	Downstream job fails, or a human has nothing to open	Retention policy
Package	A published dependency is gone	Immutable, usually forever

Most teams push a report into the middle row because that is the row the CI provider offers, then discover it behaves like a cache.

Where artifact storage is the right answer

Build outputs a later job downloads — compiled assets, container contexts, test fixtures.
Machine-readable results the pipeline itself consumes: JUnit XML, SARIF uploaded to code scanning, lcov sent to a coverage service.
Large binaries nobody reads, kept just long enough to debug a failure.

Here, short retention is a feature. Keeping a 400 MB build context for 90 days is a bill, not a safeguard.

Where it is the wrong answer

A test report, a coverage tree, a security scan, a benchmark — anything a person opens and later cites — fails as an artifact for three separate reasons:

It expires. Under a policy you frequently do not control (artifact retention).
It does not render. GitHub Actions serves artifacts as a zip; there is no viewer, so the "report link" in the PR is a download (why it is always a zip).
It is gated on repo access. A client, an auditor or a contractor who cannot authenticate to your CI cannot open it at all.

Splitting the two jobs

Keep uploading artifacts for machines. Publish documents to an address you own:

# every run, against a report id stored as a CI variable
curl -sS -X PATCH "https://commareports.com/api/v1/reports/$COMMA_REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data @<(jq -Rs '{html: .}' htmlcov/index.html)

One id, one URL, for the life of the project. Each run appends a revision rather than overwriting, so any two builds can be diffed and the link in a year-old incident doc still resolves. Per-provider setup is in publish from CI.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history. Nothing expires.

Create a permanent report URL →