Plan Run Report

The plan run report is the per-run viewer that summarises every item executed
inside a Test Plan run: status counts, per-item duration, error message,
trace, labels, attachments, and (for Test Case items) the per-step manual
flow with retry attempts.

You reach the report from any finished or in-progress plan run:

• UI: Test Plans → <plan> → Runs → <run> → View Report
• Direct URL: /ui/test-plans/<plan-id-or-numeric>/runs/<run-id>/report?namespace=<ns>

Inside the report viewer the toolbar offers five export options. Each is
available without leaving the page and produces a deterministic file —
re-running the same export on the same run yields byte-identical output, so
checksums can be used for archival audit.

Export options

Linked HTML (default)

Button: View / Download HTML.
Endpoint: GET /report.html.

A self-contained HTML document with inline CSS but linked attachments.
Images are referenced by URL (/api/v1/.../tcm/attachments/<id>/raw), so the
file is small and renders instantly inside the viewer iframe. It also opens
correctly in any browser that has session access to the Mockarty server.

Use when:

• Sharing inside the team while everyone has access to the same Mockarty
  instance.
• Embedding live in dashboards or wikis that proxy the same origin.
• The report needs to stay light-weight (no base64 inflation).

Limitation: open the file from disk on a machine without network access to
your Mockarty server and every <img> will be broken.

Standalone HTML

Button: Download standalone HTML.
Endpoint: GET /report.html?standalone=true.

The same document, with every attachment inlined as a data: URI. The
file is fully self-contained — open it from a USB stick, attach it to an
email, or drop it into a regulator’s portal. Images render inline; non-image
attachments (PDFs, JSON, logs) become click-to-download links that preserve
the original filename.

Defensive caps: each attachment ≤ 25 MiB, total inlined size ≤ 100 MiB.
Beyond either threshold the attachment is replaced with a #tcm-skipped-...
placeholder so the rest of the report still renders correctly.

Use when:

• Long-term archival.
• Air-gapped review (regulator, customer security team).
• Sending the report outside the Mockarty session boundary.

Trade-off: the file is larger (base64 inflates by 1.34×) and takes a few
seconds to build for runs with many attachments.

Print to PDF (browser)

Button: Print to PDF.

The toolbar button calls window.print() on the embedded report iframe.
The browser’s native print dialog opens with a print-friendly stylesheet
already applied (light colours, <details> forced open, page-break hints).
Pick “Save as PDF” in the destination list to capture a paper-ready archive.

Use when:

• A regulator or auditor specifically asks for PDF.
• You want page numbers and a printable layout.

Browser support: Chrome, Firefox, and Safari all produce visually consistent
output. Edge follows Chrome’s rendering. Set the destination to “Save as
PDF” (Chrome / Edge), “Microsoft Print to PDF” (Windows), or “PDF” (macOS
preview) depending on your platform.

Allure ZIP

Button: Download Allure ZIP.
Endpoint: GET /report.zip.

Allure-compatible results directory. Feed it to the Allure CLI
(allure serve report-folder/) to browse the run in the Allure UI —
suites, steps, attachments, and the categories.json / executor.json /
environment.properties sidecars.

The export writes the framework, suite, subSuite, testClass and
tag labels. It does not write severity, epic, feature, story
or package, so the Behaviors, Packages and severity views of the Allure
report stay empty. Trend widgets need Allure’s own history/ directory,
which a single export does not contain — point Allure at the same output
directory across runs to accumulate it.

Use when:

• Your CI pipeline already aggregates Allure results across projects.
• You want history graphs across many runs.

JUnit XML

Endpoint: GET /report.junit.xml.

Standard JUnit <testsuites> document. Every CI provider (GitLab CI,
Jenkins, GitHub Actions, TeamCity, Azure DevOps) parses this format.

Use when:

• The CI dashboard expects JUnit (most do).
• You want the run summary visible in pull-request checks.

Unified JSON

Endpoint: GET /report.unified.json.

Native Mockarty-shape JSON envelope. Strongly typed; preferred by SDK / CLI
consumers that want a programmatic view without parsing Allure schema.

Use when:

• Custom downstream tooling (Slack bots, internal dashboards, etc.).
• You’re scripting “if this run failed, page on-call”.

What each item type shows

Every item in the report carries its status, duration, labels and (when it
failed) the error message. Beyond that, each item type surfaces its own detail:

Load metrics also appear as parameters, so the Allure parameters table and the
JUnit properties both carry p95_ms, rps, error_rate and friends for
trend tooling.

Picking the right format

Determinism and checksums

All formats are deterministic. Two consecutive exports of the same plan run
produce byte-identical output. This means SHA-256 checksums of the export
serve as a cheap integrity proof — store the checksum alongside the file in
your archive and re-export later to verify nothing was tampered with.

Share with a stakeholder (read-only link)

When you need to send results to a customer or stakeholder who has no
Mockarty account, mint a read-only share link. On the run report toolbar
click Share — the link is copied to your clipboard. Anyone with the link
opens the run’s HTML report; no login is required.

# Mint a link (requires an authenticated session / token):
curl -X POST "$MOCKARTY/api/v1/namespaces/default/test-plans/$PLAN/runs/$RUN/report/share" \
  -H "Authorization: Bearer $TOKEN"
# → {"token":"…","url":"/api/v1/public/tcm-report/…","expiresAt":"2026-07-11T…Z"}

The link is a stateless, signed token — opening it renders the report
directly, with no database lookup. Notes:

• Opt-in. Sharing is off until an administrator sets the
  MOCKARTY_REPORT_SHARE_SECRET environment variable (the HMAC signing key).
  Until then the Share button reports that sharing isn’t configured.
• Expiry. Links last 30 days by default; pass ?ttlHours=N when minting to
  shorten that. An expired link shows a clear “this link has expired” message.
• Revocation. Rotating MOCKARTY_REPORT_SHARE_SECRET immediately
  invalidates every previously-minted link.
• Clusters. Because the env value is the signing key (so rotation can
  revoke links), set the same value on every node — otherwise a link minted
  on one node won’t open on another.
• Scope. A link grants read-only access to exactly one run’s report — it
  carries no account, no write access, and nothing about other runs.