From 2e00ad38ba13e9a25798541c07fc02bb7e0e61bb Mon Sep 17 00:00:00 2001 From: Niek Otten Date: Mon, 13 Jul 2026 12:51:56 +0200 Subject: [PATCH] ci(portal-self-service): run Vitest ahead of the production build to stop worker-start timeout (refs #68) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The frontend lane ran `nx run-many -t lint test build`, so the ~5min self-service production build shared nx's task pool with the Vitest test worker. @angular/build:unit-test's Vitest worker has hard-coded 60s/90s startup timeouts (not configurable); on a CPU-constrained CI runner the concurrent build starved the worker and it failed with "Timeout waiting for worker to respond" — flaky, since it passed on the prior commit. Split the target into a light lint+test phase and a separate build phase so tests get CPU and the worker starts well inside its window. Co-Authored-By: Claude Opus 4.8 (1M context) --- Makefile | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 77be727..3075548 100644 --- a/Makefile +++ b/Makefile @@ -50,9 +50,16 @@ endif ci: lint build unit mutation frontend verify ## frontend: install deps and run the Nx lint/test/build for the portals (pnpm + Node required) +# Tests run in their own phase, ahead of the build. The @angular/build:unit-test +# (Vitest) runner spawns a worker with a hard-coded 60s/90s startup timeout that is +# not configurable. When the ~5min production build shares the run-many pool, it +# starves that worker of CPU on constrained CI runners and Vitest fails with +# "Timeout waiting for worker to respond". Splitting the phases keeps tests off the +# heavy build's back so the worker starts well inside its window. frontend: pnpm install --frozen-lockfile - pnpm nx run-many -t lint test build + pnpm nx run-many -t lint test + pnpm nx run-many -t build ## lint: verify formatting (no changes) lint: