[FEATURE] - PR4 : Web runs

[pulk17]

[FEATURE]

In raising this pull request, I confirm the following (please check boxes):

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• I have considered, and confirmed that this submission will be valuable to others.
• I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
• I give this submission freely, and claim no ownership to its content.

My familiarity with the project is as follows (check one):

• I have never used the project.
• I have used the project briefly.
• I have used the project extensively, but have not contributed previously.
• I am an active contributor to the project.

---

Test results: the run list, a single run's detail, and queueing a new run. Depends on #1198 .

What's here
The run list groups the two platform runs of a commit together. Run detail shows progress, per-category results, output comparisons, infrastructure errors, artifacts, and the build log (paged in through /runs/{id}/logs and rejoined, since it isn't served as a file).

The comparison drawer
A failing output opens a drawer with two views.

Diff is the unified expected-vs-actual text, from the existing /diff endpoint.

Playback plays the sample with the expected and actual captions in two columns beside it. The active cue highlights in both as it plays, and clicking a cue seeks there.

This exists because of a specific problem: when ~20 tests fail because the golden output no longer matches what master produces, someone has to decide whether master is right or the baseline is stale. A text diff doesn't answer that - captions only mean something next to the picture they describe.

It uses the /expected and /actual endpoints with ?format=text, so the caption text comes through the API rather than from storage. No CORS grant on the bucket is needed, and it works the same whether the file is local or in GCS.

The honest limitation
Browsers can decode very little of this library. By container, of 178 samples: 31 mp4, 4 mov, 1 m4v will play - roughly 20%. The rest are broadcast captures (47 .mpg, 47 .ts, 23 .wtv, plus vob/dvr-ms/m2ts/mxf/asf) that no browser ships a demuxer for. I verified this in Chrome against real samples rather than assuming: mp4 loads, a real .mpg and a real .ts both fail with DEMUXER_ERROR_COULD_NOT_OPEN.

When playback fails the drawer says so plainly, offers the sample for download, and still shows both caption tracks lined up by timecode. It distinguishes "no browser can decode this container" from "the file didn't download" using the media element's own error code, because those are very different problems.

If we later want all samples playable, the answer is a one-time ffmpeg pass generating a small mp4 proxy per sample. That's a separate piece of work and ffmpeg isn't currently installed on the platform.

The cue parser
lib/cues.ts is ~40 lines handling SubRip and WebVTT, which differ only in the decimal separator. Files with no timings - the plain .txt transcripts, 85 of the outputs - yield nothing and fall back to showing the file as-is. I ran it over the 276 real .srt baselines in TestResults: 62,465 cues parsed, zero mismatches against a naive block count.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud