rbrooks/Quest-Board
Watch
1
0
Fork
You've already forked Quest-Board
 0
Code Issues 61 Pull requests 8 Projects Releases 76 Packages Wiki Activity Actions 2

ci: shard vitest and split the journeys by project (#939) #940

Merged
claude-bot merged 1 commit from ci/939-critical-path into main 2026-09-29 18:37:55 +00:00
Conversation 0 Commits 1 Files changed 4 +68 -22
claude-bot commented 2026-09-29 18:15:33 +00:00
Collaborator
Copy link

Closes #939.

The frontend and journeys jobs each took about 30 min, and both ran serially.

Frontend: two shards, two workers each.
Each CI job gets 2 CPUs. Node reports availableParallelism = 2, and vitest's default is CPUs − 1, so in CI the suite ran on one worker: 1,603 s against ~160 s on a workstation. Measured locally under the same --cpus 2 --memory 3g:

Setup Wall time
Defaults (today's CI) 579 s
--maxWorkers=2 397 s
2 shards × --maxWorkers=2 233 s and 209 s (215 files, 2,757 tests, all green)

Lint, the build and the audit run once, in shard 1. Job names are now Frontend (shard 1/2) and Frontend (shard 2/2).

Journeys: one job per Playwright project.
The suite is one worker per stack by design: login is rate limited per IP, and there's one shared seeded database. So each project (desktop, phone, keyboard) gets its own job and its own stack: its own COMPOSE_PROJECT_NAME and per-project artifact names. No spec changes, and fail-fast: false. needs: docker stays, because the stack builds from the layers that job just cached.

Flaky waits.
Two workers on 2 CPUs failed a PrepSheet wait whose explicit timeout: 4000 was shorter than the suite-wide 5 s asyncUtilTimeout. It now inherits the default. The two waits on the 1 s autosave get 8 s.

Watch on this run:

  • Three e2e stacks at once on one runner. runner-01 has 7.75 GB, and #291 was OOM kills. If this run shows memory pressure, fall back to fewer journey shards.
  • The new wall times, to compare against 31–43 min (run 11421 / 11416). Expected: frontend ~11 min per shard, and journeys ~8–10 min per project after the ~6-min docker job.

🤖 Generated with Claude Code

Closes #939. The frontend and journeys jobs each took about 30 min, and both ran serially. **Frontend: two shards, two workers each.** Each CI job gets 2 CPUs. Node reports `availableParallelism = 2`, and vitest's default is CPUs − 1, so in CI the suite ran on **one** worker: 1,603 s against ~160 s on a workstation. Measured locally under the same `--cpus 2 --memory 3g`: | Setup | Wall time | |---|---| | Defaults (today's CI) | 579 s | | `--maxWorkers=2` | 397 s | | 2 shards × `--maxWorkers=2` | **233 s and 209 s** (215 files, 2,757 tests, all green) | Lint, the build and the audit run once, in shard 1. Job names are now `Frontend (shard 1/2)` and `Frontend (shard 2/2)`. **Journeys: one job per Playwright project.** The suite is one worker per stack by design: login is rate limited per IP, and there's one shared seeded database. So each project (desktop, phone, keyboard) gets its own job and its own stack: its own `COMPOSE_PROJECT_NAME` and per-project artifact names. No spec changes, and `fail-fast: false`. `needs: docker` stays, because the stack builds from the layers that job just cached. **Flaky waits.** Two workers on 2 CPUs failed a PrepSheet wait whose explicit `timeout: 4000` was *shorter* than the suite-wide 5 s `asyncUtilTimeout`. It now inherits the default. The two waits on the 1 s autosave get 8 s. **Watch on this run:** - Three e2e stacks at once on one runner. runner-01 has 7.75 GB, and #291 was OOM kills. If this run shows memory pressure, fall back to fewer journey shards. - The new wall times, to compare against 31–43 min (run 11421 / 11416). Expected: frontend ~11 min per shard, and journeys ~8–10 min per project after the ~6-min docker job. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
ci: shard vitest and split the journeys by project (#939)
All checks were successful
CI / Backend lint (ruff) (pull_request) Successful in 47s
Details
CI / Summarisation accuracy eval harness (stub provider) (pull_request) Successful in 55s
Details
CI / Feedback site tests (pull_request) Successful in 1m2s
Details
CI / Bot/backend version sync (pull_request) Successful in 34s
Details
CI / Does this change touch the recording path? (pull_request) Successful in 20s
Details
CI / Docker image build (pull_request) Successful in 51s
Details
CI / Bot tests and audit (pull_request) Successful in 1m55s
Details
CI / Frontend (shard 2/2) (pull_request) Successful in 5m49s
Details
CI / Frontend (shard 1/2) (pull_request) Successful in 11m52s
Details
CI / End-to-end journeys (keyboard) (pull_request) Successful in 7m47s
Details
CI / End-to-end journeys (desktop) (pull_request) Successful in 8m48s
Details
CI / Synthetic session harness (no GPU, no LLM) (pull_request) Successful in 13m35s
Details
CI / Backend migration, tests, and audit (pull_request) Successful in 18m17s
Details
CI / End-to-end journeys (phone) (pull_request) Successful in 11m39s
Details
a746668ecb 
The frontend and journeys jobs were each ~30 min, and both were serial.

Vitest ran on one worker. A CI job gets 2 CPUs, Node reports
availableParallelism = 2, and vitest defaults to CPUs - 1, so 215 files ran
one at a time: 1,603 s against ~160 s on a workstation. Measured locally
under the same --cpus 2 --memory 3g: defaults 579 s; --maxWorkers=2 397 s;
two shards with --maxWorkers=2 233 s and 209 s. The frontend job is now a
two-shard matrix, and lint, build and audit run once, in shard 1.

The journeys stay one worker per stack (login rate limit per IP, one shared
seeded database), so they become a matrix over the three Playwright
projects, each with its own stack: its own Compose project name and
artifacts. No spec changes. needs: docker stays for the warm layer cache.

Two workers on 2 CPUs exposed a flaky PrepSheet wait whose explicit 4000 ms
timeout was below the suite-wide 5000 ms asyncUtilTimeout. It now inherits
the default, and the two autosave waits (1 s debounce) get 8000 ms.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
claude-bot scheduled this pull request to auto merge when all checks succeed 2026-09-29 18:15:41 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
backend
Issue related to the backend

  
bot
Issue related to the bot

  
bug
Something is not working

  
duplicate
This issue or pull request already exists

  
enhancement
New feature

  
frontend
Issue related to the frontend

  
help wanted
Need some help

  
invalid
Something is wrong

  
question
More information is needed

  
recording
Issue related to the recording system

  
security
Security hardening / vulnerability work

  
wontfix
This won't be fixed

No labels
backend
bot
bug
duplicate
enhancement
frontend
help wanted
invalid
question
recording
security
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
rbrooks/Quest-Board!940
No description provided.