@@ -192,14 +192,25 @@ jobs:
192192 fail-fast : false
193193 matrix :
194194 include :
195- # Each cloud shard boots its own fresh dev stack. On 4 vCPU runners,
196- # four fatter shards keep the longest shard below selfhost while saving
197- # four runner boots and four warm cache restores.
198- - { target: cloud, shard: 1/4, shard-name: 1of4 }
199- - { target: cloud, shard: 2/4, shard-name: 2of4 }
200- - { target: cloud, shard: 3/4, shard-name: 3of4 }
201- - { target: cloud, shard: 4/4, shard-name: 4of4 }
202- - target : selfhost
195+ # PGlite is deliberately single-connection, and under a sustained
196+ # multi-minute shard it can stop accepting postgres sockets. Keep
197+ # every hermetic dev stack short: eight serial shards remove that
198+ # lifetime-dependent failure and put cloud below the selfhost lane.
199+ - { target: cloud, shard: 1/8, shard-name: 1of8 }
200+ - { target: cloud, shard: 2/8, shard-name: 2of8 }
201+ - { target: cloud, shard: 3/8, shard-name: 3of8 }
202+ - { target: cloud, shard: 4/8, shard-name: 4of8 }
203+ - { target: cloud, shard: 5/8, shard-name: 5of8 }
204+ - { target: cloud, shard: 6/8, shard-name: 6of8 }
205+ - { target: cloud, shard: 7/8, shard-name: 7of8 }
206+ - { target: cloud, shard: 8/8, shard-name: 8of8 }
207+ # Selfhost shards the same way: each shard is its own runner booting
208+ # its own fresh instance (own port block + data dir), so the
209+ # project's shared-bootstrap-admin assumption stays intact per shard
210+ # and `fileParallelism: false` still serializes within a shard.
211+ - { target: selfhost, shard: 1/3, shard-name: 1of3 }
212+ - { target: selfhost, shard: 2/3, shard-name: 2of3 }
213+ - { target: selfhost, shard: 3/3, shard-name: 3of3 }
203214 runs-on : blacksmith-4vcpu-ubuntu-2404
204215 timeout-minutes : 30
205216 steps :
@@ -241,20 +252,20 @@ jobs:
241252
242253 # The globalsetup boots the target's own dev server (ports are claimed
243254 # per checkout, so this is hermetic) and tears it down after the run.
244- # --retry=2: browser scenarios can still hit isolated waitFor timeouts
245- # (single-test waitFor timeouts, not systemic failures); a retry on the
246- # same booted stack clears them .
255+ # Do not retry scenarios: retries hide flakes and multiply slow timeout
256+ # failures. The fixtures and process lifecycle are deterministic enough
257+ # that the first result is the result .
247258 - name : Run cloud scenarios
248259 if : matrix.target == 'cloud'
249260 env :
250261 MCP_SESSION_TIMEOUT_MS : " 3000"
251262 MCP_PAUSED_SESSION_IDLE_TIMEOUT_MS : " 6000"
252- run : bunx vitest run --project cloud --retry=2 ${{ matrix.shard && format('--shard={0}', matrix.shard) || '' }}
263+ run : bunx vitest run --project cloud ${{ matrix.shard && format('--shard={0}', matrix.shard) || '' }}
253264 working-directory : e2e
254265
255266 - name : Run selfhost scenarios
256267 if : matrix.target == 'selfhost'
257- run : bunx vitest run --project selfhost --retry=2
268+ run : bunx vitest run --project selfhost ${{ matrix.shard && format('--shard={0}', matrix.shard) || '' }}
258269 working-directory : e2e
259270
260271 # Failed runs keep their trace.zip / session.mp4 / step screenshots in
@@ -268,10 +279,7 @@ jobs:
268279 retention-days : 7
269280
270281 e2e-local :
271- name : E2E (stdio MCP)
272- # Skipped on pull_request: the local scenario boots a real `executor web`
273- # plus a browser and is currently flaky on PRs. Still runs on push to main.
274- if : github.event_name != 'pull_request'
282+ name : E2E (local)
275283 runs-on : blacksmith-4vcpu-ubuntu-2404
276284 timeout-minutes : 20
277285 steps :
@@ -314,15 +322,10 @@ jobs:
314322 run : bunx playwright install --with-deps chromium chromium-headless-shell
315323 working-directory : e2e
316324
317- # The `local` project is excluded from the default `test` chain (each
318- # scenario boots its own `executor web`). Run just the stdio MCP scenario
319- # here: it is the auto-connect / env-as-secret regression guard, and
320- # running it alone avoids the boot-resource accumulation and the
321- # pre-existing browser flakiness of the rest of the local suite. Expanding
322- # to the full `local` project (bun run test:local) is a follow-up once
323- # those are stabilized.
324- - name : Run the stdio MCP scenario
325- run : bunx vitest run --project local local/stdio-mcp.test.ts
325+ # Each scenario owns its server, browser, data directory, and descendants;
326+ # run the complete hermetic suite on PRs without scenario retries.
327+ - name : Run local scenarios
328+ run : bunx vitest run --project local
326329 working-directory : e2e
327330
328331 desktop-smoke :
0 commit comments