Aman-Mittal opened a new issue, #259: URL: https://github.com/apache/fineract-backoffice-ui/issues/259
## Business value The e2e suite runs on a single worker and is now the longest thing on the critical path of every pull request. Measured on this repository: | Project | Tests | Files | CI wall-clock | | --- | --- | --- | --- | | `mocked` | 220 | 13 | ~11m45s (job `92945974006`, 17:31:53 → 17:43:38) | | `backend` | 23 | 10 | longer — brings up a Fineract stack first | `playwright.config.ts` pins `workers: process.env.CI ? 1 : undefined`, deliberately: the specs create real records against a shared Fineract, and parallel workers were producing interference. So the suite cannot be sped up by adding workers inside one job — the parallelism has to come from running *disjoint sets of tests in separate jobs*, each with its own backend. That is exactly what the platform repository does. `apache/fineract`'s [`build-e2e-tests.yml`](https://github.com/apache/fineract/blob/develop/.github/workflows/build-e2e-tests.yml) runs a **20-way shard matrix**: ```yaml strategy: fail-fast: false matrix: shard_index: [1, 2, …, 20] total_shards: [20] ``` with `scripts/split-features.sh` dividing the feature files, a **fresh docker stack per shard**, and per-shard artifacts uploaded on failure. The shape is proven in the same project family, on the same kind of test. Why this matters beyond wall-clock: a suite slow enough to be annoying is a suite people stop waiting for. The cost is paid on every push, and this repo is under active concurrent development. ## What makes it tractable here Playwright has native sharding — no equivalent of `split-features.sh` is needed: ``` npx playwright test --project=mocked --shard=${{ matrix.shard }}/${{ matrix.total }} ``` It splits by test and balances across shards. Combined with the `blob` reporter, the shards' results merge back into a single report: ``` # per shard npx playwright test --shard=1/4 --reporter=blob # after the matrix npx playwright merge-reports --reporter=html ./all-blob-reports ``` ## Describing the change **Start with the `mocked` project only.** It needs no Fineract and no seeding, so a shard is just another checkout — the sharding is nearly free and the payoff is immediate. Four shards should take ~11m45s to roughly 3–4m including setup. - Add `strategy.matrix` with `fail-fast: false` to the `mocked` job in `.github/workflows/e2e.yml`. - Pass `--shard=${{ matrix.shard }}/${{ matrix.total }}`. - Switch the shard reporter to `blob`, upload each shard's blob as an artifact, and add a dependent job that downloads them and runs `merge-reports`. - Keep the existing PR summary comment working off the merged report rather than off one shard, or it will report a quarter of the results as if they were all of them. **Treat the `backend` project as a separate decision, in a follow-up.** It is 23 tests, and each shard would pay the full docker bring-up — database, `init-db.sql`, waiting on the actuator health endpoint — so naive sharding could make it *slower*, not faster. It also needs care that mocked does not: - The specs create real records and some depend on state they set up earlier in the same file. Playwright's sharding splits by test, so two tests in one file can land in different shards. `fullyParallel: true` is already set, which means the suite is *supposed* to tolerate that, but it has never actually been run that way — this needs verifying rather than assuming. - Shards must not share one Fineract. `apache/fineract` gives each shard its own stack for exactly this reason. Sharing one would reintroduce the interference `workers: 1` exists to prevent. - One known example to check: `teller-cash-management.spec.ts` allocates a cashier and the platform refuses overlapping date ranges for the same staff member across *any* teller, which is why that spec creates fresh staff per run. Similar cross-test coupling elsewhere would surface only under sharding. So: shard `mocked` first, measure, then decide on `backend` with numbers in hand. ## Scope In scope: sharding the `mocked` e2e job, blob reporting, report merging, and keeping the PR summary accurate. Out of scope for the first PR: sharding the `backend` job, changing `workers` or `retries`, and any change to the specs themselves. ## Notes for whoever picks this up - `.github/workflows/e2e.yml` holds both jobs; the concurrency group at the top already cancels superseded runs and should be left alone. - `playwright.config.ts` sets `reporter: 'html'` — the shard jobs need `blob`, which is best passed on the command line rather than changed globally, so a local run still produces the HTML report developers expect. - `outputDir` is deliberately outside the repo (the dev server's file watcher races Playwright's artifact deletion and dies); keep that. - Verify by comparing the merged report's total against `npx playwright test --list --project=mocked` — currently 220. A sharding mistake shows up as a *smaller* total that still reports green, which is the failure mode to watch for. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
