What is an HTML report?

A generated web page that presents the results of a run — tests, coverage, a security scan, a profile, an analysis — as browsable output rather than console text. It is produced by a tool, not written by hand, and it is usually interactive: sortable tables, expandable failures, charts, drill-downs into source.

Why do HTML reports break when you send them to someone?

Because three conditions that held on the machine that generated them disappear in transit: the whole output directory was present, the origin was permissive, and the network reached every CDN the page references. A report is only really tested the first time someone else opens it.

What is the difference between an artifact and a report?

An artifact is a file a CI job stores for later retrieval, governed by a retention policy and addressed by a link that expires. A report is a document meant for a person to read and cite. The mistake most teams make is storing the second as the first.

Which report format should a tool emit for machines?

JUnit XML for test results and SARIF for static analysis and security findings are the two de-facto interchange formats almost every CI system and code host can ingest. HTML is the human-readable sibling; most tools emit both, and both are worth keeping.

Glossary

The vocabulary that turns up the moment a generated report has to leave the machine that made it. Each entry is a definition first, then the part that actually bites in practice.

Report formats and outputs

HTML report — what one is, and why it is never just one file
Self-contained HTML — the single-file export mode, and its ceiling
Code coverage — line, branch, statement, and what a percentage hides
JUnit XML — the interchange format with no specification
SARIF — the OASIS standard for static analysis findings
SBOM — CycloneDX, SPDX, and what a bill of materials is for
Flame graph — why the x-axis is not time
Mutation testing — the coverage metric that can actually fail
Flaky test — the definition, and why the report matters more than the fix
.ipynb — notebook files, and what survives an HTML export

CI and storage

Build artifact — what CI keeps, and on whose terms
Artifact retention — the four mechanisms that delete your link
Static site hosting — serving files with no server
Presigned URL — signed, time-boxed object access
MIME type — the header that decides render versus download

Browser behaviour

Same-origin policy — and the opaque file:// origin
Content Security Policy — what the host allows a page to load
Mixed content — HTTP subresources on an HTTPS page
Data URI — inlining assets, at a 33% tax
iframe sandbox — running untrusted HTML safely

Agents

Model Context Protocol (MCP) — how an agent gets tools
Agent artifact — the output an agent produces that outlives its session

Why these terms cluster together

Almost every entry above is a step on the same path. A tool generates a directory of HTML. CI stores it as an artifact under a retention policy. Someone links it. The link 404s, or the page opens blank because the origin was file://, or it downloads instead of rendering because the MIME type was wrong, or the charts are missing because CSP refused the CDN.

The terms are the failure modes, named.

Publishing the whole output directory to an address you own collapses most of them: assets travel with the entry file, the origin is a real HTTPS origin, the Content-Type is correct, and the link does not have an expiry date attached to someone else's storage policy.

Try it

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

Publish a report that opens for everyone →

Report types — 200+ per-tool publishing guides
Troubleshooting — when a report breaks after it leaves your machine
Publish from CI · Comma by role