Summary
The end-to-end suite runs strictly serially. playwright.config.ts sets a global workers: 1, so every spec waits for the previous one regardless of which project it belongs to.
Measured on the first CI execution of the e2e job (3m13s total):
| Step |
Time |
| Start gateway (including the image pull) |
30s |
| Install Playwright browsers |
23s |
| Run E2E tests |
117s |
| Everything else |
~23s |
So the serial execution is where the time is, and it is the only part that grows with every spec added.
Proposed solution (optional)
The cap is not arbitrary. There are two projects: scripts-serial drives a live gateway, and mocked intercepts specific gateway responses to reach states a healthy gateway will not produce on demand. The mocked project still reaches the live gateway for everything it does not intercept, in particular entity discovery, so both projects share one container. A per-project workers: 1 would not help, because two separate single-worker projects still run concurrently against that one gateway; only the global cap actually serialises them.
Two ways out:
- Intercept every gateway request in the
mocked project, not just the ones each scenario cares about, so it needs no container at all. It could then run with parallel workers while scripts-serial keeps its single worker. This is the cheaper option and it also makes those specs independent of the gateway image.
- Give the mocked project its own gateway container. Heavier, and it buys less than option 1.
Additional context (optional)
Not urgent: at 3m13s the job is not a bottleneck for anybody today, and the serialisation is what keeps the suite deterministic. This is worth doing when the suite grows enough for the 117s to become annoying, and it is filed now so the reason for the cap is not re-derived from scratch.
Introduced with the harness in #91.
Summary
The end-to-end suite runs strictly serially.
playwright.config.tssets a globalworkers: 1, so every spec waits for the previous one regardless of which project it belongs to.Measured on the first CI execution of the
e2ejob (3m13s total):So the serial execution is where the time is, and it is the only part that grows with every spec added.
Proposed solution (optional)
The cap is not arbitrary. There are two projects:
scripts-serialdrives a live gateway, andmockedintercepts specific gateway responses to reach states a healthy gateway will not produce on demand. The mocked project still reaches the live gateway for everything it does not intercept, in particular entity discovery, so both projects share one container. A per-projectworkers: 1would not help, because two separate single-worker projects still run concurrently against that one gateway; only the global cap actually serialises them.Two ways out:
mockedproject, not just the ones each scenario cares about, so it needs no container at all. It could then run with parallel workers whilescripts-serialkeeps its single worker. This is the cheaper option and it also makes those specs independent of the gateway image.Additional context (optional)
Not urgent: at 3m13s the job is not a bottleneck for anybody today, and the serialisation is what keeps the suite deterministic. This is worth doing when the suite grows enough for the 117s to become annoying, and it is filed now so the reason for the cap is not re-derived from scratch.
Introduced with the harness in #91.