The --skip-npm-install switch merged but is not in a release yet - 1.18.2 predates it.

This T433561 should help quite a bit getting a handle on capture errors of all kinds

https://gitlab.wikimedia.org/repos/test-platform/pixel/-/merge_requests/20

Any thoughts on https://gerrit.wikimedia.org/r/c/integration/quibble/+/1299658 ?

Yes

There was a Pixel run over the weekend where the job failed (e.g. no screenshots for test) https://pixel-reports.wmcloud.org/mobile/2026-07-03T08-20-41Z/ In this case is it possible for Pixel not to fast forward for the next check and to retry instead? A compromise might be only fast forwarding the branch at the end a day?

Note: T424352: Pixel tests using SCROLL command mostly fail is the source of much of our flakiness. I think we should perhaps disable all tests using SCROLL in the interim to avoid that. If I pushed a change would you be able to review @Mhurd ?

https://gitlab.wikimedia.org/repos/test-platform/pixel/-/merge_requests/16

Bottom line: of the two options in the ticket, the rolling baseline is the one we can ship within the ~2-week window. The approval ("mark as checked") option is feasible but materially more invasive and doesn't fit the time box

^ Strike-throughs above from conversation with @thcipriani

Does bumping castor06 to g4.cores16.ram64.disk20.10xiops sound worth a try?

Root cause. integration-castor06 (the shared CI dependency-cache host) is saturating the disk I/O on its cache volume. Agents restore with rsync --contimeout 3 || : - a 3-second timeout to connect to castor06's rsync daemon - so when the volume is I/O-pinned and the daemon can't serve the restore in time, rsync aborts, the || : silently swallows it, the cache comes back empty, and npm ci re-downloads everything over the network (seconds warm, minutes cold). That's the median regression here (10:47 -> 11:56), and it's not specific to this job - unrelated jobs, including trivial ones, regressed on the same days

I noticed when talking talking with @Peter the other day that the upstream project is "deprecated and is not accepting new features or general bug fixes" :(

Confirmed the suspicion: Quibble's dependency step runs npm install whenever --commands is set, even with no JS stages.
The patch adds an opt-in --skip-npm-install that skips it while keeping Composer deps (--skip-deps would drop both and break PHPUnit).
Opt-in because some --commands jobs do need Node (e.g. Wikibase browser tests), and narrowing this gate blindly caused T422843.

@Peter On it!

Upstream PR filed:

Should we close this?

T423060: Investigate running QUnit tests in parallel - spike conclusion

Possibly related?

Oops I was basing it on the SQLite comment here and here

Could SQLite WAL mode (allows concurrent readers alongside a writer) perhaps help here?

This tried setting synchronous = OFF, which reduces fsync overhead, but doesn't address concurrent access. Has anyone tried PRAGMA journal_mode = WAL? WAL mode is the SQLite setting that allows concurrent readers alongside a writer, which seems more directly relevant to the parallelization blocker described here.

https://gitlab.wikimedia.org/repos/test-platform/mediawiki-quickstart/-/merge_requests/77

https://gitlab.wikimedia.org/repos/test-platform/mediawiki-quickstart/-/merge_requests/76

16 of 17 tests now pass with this

Closing as invalid - must have been a transient issue as it's now showing as passing in https://quickstart-ci-components.wmcloud.org

Good
Branch protection: Done. main is now protected — direct pushes are blocked, changes must go through merge requests