From cba389515cabd5517daa28404883f293e1dff4ef Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marc-Andr=C3=A9=20Bombeck?= Date: Tue, 1 Sep 2026 20:28:32 +0200 Subject: [PATCH] ci: split the integration suite four ways and widen the guard Three of the last four pushes to main failed the integration workflow without a single failing test. Shard 1 of 3 was still logging green results when the 25-minute job timeout cancelled it; the same tests in the same shard had run in 13 minutes the day before. A slow runner day doubles every test's wall time, and a guard under twice the ordinary run cannot absorb that. Four shards keep each slice around fifty files, and the guard moves to 40 minutes, three times an ordinary run. A wedged test still fails through vitest's own 60-second budget, so the job timeout only has to catch a container that never boots. The fan-in job is unchanged; it still refuses a matrix with any cancelled shard. --- .github/workflows/integration.yml | 28 ++++++++++++++++------------ 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/.github/workflows/integration.yml b/.github/workflows/integration.yml index 15b9696ac..1bb859920 100644 --- a/.github/workflows/integration.yml +++ b/.github/workflows/integration.yml @@ -10,21 +10,25 @@ permissions: contents: read jobs: - # The suite outgrew a single runner, and then a half-suite outgrew a slow - # one: two shards cleared in ~14 minutes on a quiet day, but with six pull - # requests running side by side the larger shard hit the same 25-minute - # guard the split was meant to escape. Three shards keep the biggest slice - # around 60 files, which clears the guard with real headroom even on the - # slowest runner observed. Each shard boots its own Postgres testcontainer; - # the timeout stays a hang detector, not a performance budget. + # The suite outgrew a single runner, then a half-suite outgrew a slow one, + # and then a third of it did too. Three shards of about 68 files cleared in + # 13 minutes on an ordinary runner, but a slow runner day ran every test at + # twice its usual duration and the first shard was still working through + # its list when the 25-minute guard cut it off: three of four pushes to main + # between 2026-08-31 and 2026-09-01 failed that way, with green tests logged + # up to the last second. Four shards keep each slice around 50 files, and + # the guard sits at three times the ordinary run rather than under two. A + # wedged test still surfaces through vitest's own 60-second budget, so the + # job timeout only needs to catch a container that never boots. Each shard + # boots its own Postgres testcontainer. shard: runs-on: ubuntu-latest - timeout-minutes: 25 + timeout-minutes: 40 strategy: fail-fast: false matrix: - shard: [1, 2, 3] - name: integration shard ${{ matrix.shard }}/3 + shard: [1, 2, 3, 4] + name: integration shard ${{ matrix.shard }}/4 steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 @@ -44,7 +48,7 @@ jobs: # vitest a stray positional argument and the shard flag never applies — # both "shards" then run the full suite. Proven by a paired local run # before this workflow shipped. - - run: pnpm exec vitest run --config vitest.integration.config.mts --shard=${{ matrix.shard }}/3 + - run: pnpm exec vitest run --config vitest.integration.config.mts --shard=${{ matrix.shard }}/4 env: # The integration suite boots a Postgres testcontainer and points # Prisma at it via DATABASE_URL set inside `tests/integration/setup.ts`. @@ -60,7 +64,7 @@ jobs: SESSION_SECRET: "integration-tests" # Branch protection requires a check named exactly "integration". This job - # carries that name and answers for both shards: it fails when any shard + # carries that name and answers for every shard: it fails when any shard # failed or was cancelled, so a half-green matrix cannot satisfy the gate. integration: runs-on: ubuntu-latest