Does Ginkgo produce an HTML report?

No. Ginkgo v2 writes machine-readable reports with `--junit-report`, `--json-report` and `--teamcity-report`. HTML comes from converting the JUnit file with a tool like `junit2html`.

Which report flag should I use?

`--junit-report=report.xml` if you want an HTML conversion or CI test-summary integration. `--json-report` if you are building something custom — it keeps Ginkgo's own node tree, which JUnit flattens.

Does this work with parallel specs?

Yes. `ginkgo -p --junit-report=report.xml` aggregates the parallel processes into one report file, so you publish one page rather than one per node.

How do I publish from CI?

PATCH the same report id from the job with `if: always()`. Red runs are the ones with a reader, so a publish step that only fires on green is the wrong way round.

Can reviewers comment on a specific spec?

Yes. Threads anchor to the rendered content, so a note on a flaky `It` block stays attached to that block across later runs.

Share a Ginkgo test report

Ginkgo's whole pitch is that specs read like the behaviour they describe. That survives right up until the run finishes, at which point what leaves the machine is ok github.com/you/thing 14.204s and a wall of scrollback.

Ginkgo v2 already writes structured reports. It just doesn't render them.

Emit JUnit, convert it

go install github.com/onsi/ginkgo/v2/ginkgo@latest
pip install junit2html

ginkgo -r -p --junit-report=report.xml ./... || true
junit2html report.xml ginkgo.html

-p runs the specs in parallel and still writes a single aggregated report.xml. || true keeps the pipeline alive long enough to publish a failing run — keep a separate ginkgo -r step as the actual gate.

Publish it

Drag ginkgo.html into the app, or from CI:

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html ginkgo.html \
        --arg title "Ginkgo — $GITHUB_REF_NAME" '{title: $title, html: $html}')"

One report id per suite, PATCHed every run. The URL is stable; the history behind it is the flake record.

The JSON report, if you want more

--json-report=report.json keeps the container hierarchy — Describe inside Describe, the spec's own file and line, the By steps — that JUnit throws away. If you already render your own summary page from it, publish that HTML instead; nothing about the flow changes.

Why it is worth a URL

Anchored threads on the spec that keeps failing, so "this one is timing out on the CI runner, not in the code" lands next to the failure. See commenting on HTML.
Revisions — the same id across runs turns "is this new?" into a diff.
A routine if you run the suite nightly and want the trend maintained without anyone remembering.

Limits

Entry HTML: 5 MB. Assets: 25 MB per file, 250 MB and 500 files total.
60 requests/minute per token.

Try it

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

Publish a test report →