Skip to content

Epic: the frontend e2e job stops being a fourteen-minute wait #1308

Description

@ExtraToast

fe-e2e is the longest single job in validate.yml. Measured on run 35329092557, a green run on a PR branch:

fe-e2e total 13m58s
setup (checkout, node, playwright install) 37s
vite build, preview and dev server boot 38s
Playwright, 878 tests, 8 workers 12m29s
coverage conversion 8s
whole validate run 15m19s

Almost all of it is the test run itself, so it parallelises well. This epic cuts the job to a few minutes and then removes work from it outright.

What the measurement also says

Sharding fe-e2e alone does not make the pipeline meaningfully faster. api-static (5m9s) → build-images api (4m43s) → system-tests shards (4m40s) is a 14m49s chain finishing at 09:36:11, against fe-e2e at 09:36:35. The two paths are co-critical. Take fe-e2e to four minutes and the run goes from 15m19s to roughly 14m55s.

That is worth doing anyway — fe-e2e stops being able to regress further, and the frontend feedback loop shortens for anyone watching that one job — but the pipeline number does not move until the API chain does. Five minutes of Kotlin compilation followed by four and three-quarter minutes of building an image from what was just compiled is the other half of the problem, and it is not scoped here.

The decisions

  • Playwright's own --shard, not a bespoke partition. One line, no hashing to maintain. It balances by spec file rather than duration, which is a known limitation to measure rather than pre-empt.
  • Six shards, matching the system-tests matrix already in this workflow.
  • Four workers per shard, one per vCPU. Oversubscription bought cover for the tail of an 878-test run; a 146-test slice does not have one.
  • No retries. The single retry existed to absorb assertions starved by 8 workers on 4 vCPUs. With that gone, a retry would hide a real flake instead. trace: retain-on-failure replaces on-first-retry so the first failure is still readable.
  • Coverage merges in a fan-in job. Six shards each hold part of the picture. convert-frontend-coverage.mjs already merges recursively, so one downstream job publishes frontend-e2e-coverage under its existing name.
  • Validate complete is the only required check, so renaming fe-e2e into a matrix needs no branch-protection change.

Slices

Deliberately out of scope

  • The api-staticbuild-imagessystem-tests chain described above.
  • Shard balance. --shard splits by spec file; module-smoke.spec.ts is two tests at ~35s each and the esports-* specs are heavy. Read the per-shard times off the first sharded run before adding machinery for it.
  • The dev server on port 4174 boots in all six shards although only the shard holding module-smoke needs it. Same measurement decides whether it is worth separating.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:ci-cdciepicA parent issue holding a set of slices

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions