Artifacts and Uploads

[enact-on]

Issue 1 : Upload video/screenshot attachments, not just traces

Currently isTraceAttachment (packages/core/src/lib/ingest-client.ts:129-132) gates which attachment bodies get uploaded in both the reporter (packages/reporter/src/index.ts:140-151) and CLI (packages/cli/src/upload.ts:31-34) — only trace.zip is sent. Videos and screenshots are recorded in the run JSON as metadata only (name/contentType/path/hasBody), so their path is a local CI-runner path the server can never fetch, and the dashboard has nothing to link to.

Ask: widen the upload path so video/* and image/* attachments (not just zips) get uploaded via the existing client.uploadArtifact() call, storing each as an artifact row keyed by test — same mechanism traces already use.

Needs a decision before implementing:

• Size/quota impact — videos are much larger than traces and one can exist per retry; should this be opt-in (a reporter option, e.g. uploadAttachments: ['video', 'screenshot']) or upload everything by default?
• Should this only fire on-failure (matching Playwright's own default video/screenshot retention policy) or unconditionally per effectiveAttachments?
• Retention/storage cost implications for purge-expired-runs and plan limits (packages/server/src/billing/retention.ts, usage.ts).

Touches: packages/core/src/lib/ingest-client.ts, packages/reporter/src/index.ts, packages/cli/src/upload.ts.

---

Issue 2 : Render video/screenshot attachments as links on the run page

RunPage.vue currently lists every attachment as an inert text badge (packages/web/src/pages/RunPage.vue) — only the trace gets a clickable "View trace" pill. Once an attachment has a resolved url (blocked on the upload work above landing), the badge should be a real link.

Ask: turn each attachment badge into an <a> pointing at a.url (opens the raw file in a new tab) when a URL is present; keep it inert text when it isn't (e.g. old runs ingested before that lands, or attachments still gated off by whatever opt-in that issue decides on).

Nice-to-have, not required for v1: an inline video player / image lightbox instead of a raw-file new tab.

Touches: packages/web/src/pages/RunPage.vue. Depends on the upload-attachments issue.

---

[joris-gallot]

Diagnosis is right, isTraceAttachment gates uploads to zips, so video/screenshot land as metadata with a CI-local path the server can't fetch

Your screenshot tells me you're running without traces, on a passing test, that rules out the on-failure gating the issue suggests: it would upload nothing for you

Worth knowing in the meantime: screenshots are already viewable if you turn trace on, the viewer renders image attachments inline, including toHaveScreenshot expected/actual/diff triplets with a comparison slider

Are you self-hosting? It changes the answer, self-host has no quota and no retention sweep, so uploading everything unconditionally is fine. On cloud I'd want a storage cap in place first, since an uptime spec on a schedule means a video per run, kept for the whole retention window

[enact-on]

You are right, I am right now self hosting to see what it has to offer and if its right tool.

I tried with trace on, let me give you my observations

1. inline buttons don't work

2. Trace now shows screenshot, but video downloads htm file, still not viewable.

Thanks @joris-gallot

[joris-gallot]

Both fixed in #30.

The webm was in the trace zip all along and the link was right: Chromium never routes an <a download> request through the service worker, so it hit the static server and came back with its SPA fallback page, hence the ~1 kB .htm. That affected every attachment type. The viewer now fetches in-page and saves a blob, and videos play inline.

Badges now open the viewer's Attachments tab. No extra upload needed, since your screenshots and videos ride inside trace.zip already.

Still open: runs with video/screenshot and no trace, where nothing gets uploaded. Are you running any project without trace?