Stabilize sharded e2e CI concurrency (#6312)

Co-authored-by: Neil <neil@stably.ai>

.github/workflows/e2e.yml

@@ -81,16 +81,26 @@ jobs:
       fail-fast: false
       matrix:
         include:
-          - shard: '1/5'
-            shard_name: 1-of-5
-          - shard: '2/5'
-            shard_name: 2-of-5
-          - shard: '3/5'
-            shard_name: 3-of-5
-          - shard: '4/5'
-            shard_name: 4-of-5
-          - shard: '5/5'
-            shard_name: 5-of-5
+          - shard: '1/10'
+            shard_name: 1-of-10
+          - shard: '2/10'
+            shard_name: 2-of-10
+          - shard: '3/10'
+            shard_name: 3-of-10
+          - shard: '4/10'
+            shard_name: 4-of-10
+          - shard: '5/10'
+            shard_name: 5-of-10
+          - shard: '6/10'
+            shard_name: 6-of-10
+          - shard: '7/10'
+            shard_name: 7-of-10
+          - shard: '8/10'
+            shard_name: 8-of-10
+          - shard: '9/10'
+            shard_name: 9-of-10
+          - shard: '10/10'
+            shard_name: 10-of-10
 
     steps:
       - name: Checkout
@@ -142,8 +152,9 @@ jobs:
           path: out/
 
       # Why: the Electron suite is wall-clock constrained on OSS runners, but
-      # raising workers on one runner OOMs. Sharding keeps each VM at 4 workers
-      # while splitting the 91-test headless suite across separate runners.
+      # multiple Electron apps on one Xvfb VM contend on git/Chromium resources.
+      # Sharding keeps each VM at one Playwright worker while splitting the
+      # headless suite across separate runners.
       # SKIP_BUILD makes Playwright globalSetup reuse the single build job's
       # artifact instead of starting five concurrent electron-vite builds.
       # ORCA_E2E_FORWARD_APP_LOGS keeps startup failures visible when Electron

tests/playwright.config.ts

@@ -26,10 +26,10 @@ export default defineConfig({
   // substantially. The few visible-window tests that still rely on real
   // pointer interaction are marked serial in their spec file instead.
   fullyParallel: true,
-  // Why: each CI worker launches real Electron/Chromium process trees. Ubuntu
-  // runners have 4 vCPUs, but 4 parallel apps can exhaust Chromium GPU/zygote
-  // subprocess startup under Xvfb, so keep headless E2E below that ceiling.
-  workers: process.env.CI ? 2 : undefined,
+  // Why: each CI worker launches a real Electron/Chromium process tree against
+  // a mutable seeded repo. Release runners showed two apps per VM can contend
+  // on Xvfb/git enough to create false E2E failures, so CI scales by shards.
+  workers: process.env.CI ? 1 : undefined,
   forbidOnly: !!process.env.CI,
   retries: 0,
   reporter: 'list',