From 0cd785d8a5b8a34a922efc5dd133f2ea3cd467ed Mon Sep 17 00:00:00 2001 From: Peter Steinberger Date: Wed, 22 Apr 2026 04:37:42 +0100 Subject: [PATCH] ci: stabilize parity gate runner --- .github/workflows/parity-gate.yml | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/.github/workflows/parity-gate.yml b/.github/workflows/parity-gate.yml index 9ea116293d3..516bae7573e 100644 --- a/.github/workflows/parity-gate.yml +++ b/.github/workflows/parity-gate.yml @@ -25,8 +25,8 @@ jobs: parity-gate: name: Run the GPT-5.4 / Opus 4.6 parity gate against the qa-lab mock if: ${{ github.event.pull_request.draft != true }} - runs-on: blacksmith-8vcpu-ubuntu-2404 - timeout-minutes: 20 + runs-on: blacksmith-32vcpu-ubuntu-2404 + timeout-minutes: 30 env: # Fence the gate off from any real provider credentials. The qa-lab # mock server + auth staging (PR N) should be enough to produce a @@ -34,11 +34,12 @@ jobs: # leak into the job env, fail hard instead of silently running # against a live provider and burning real budget. # - # The parity pack has 11 isolated scenario workers. The Blacksmith - # runner label can still expose a small 2-vCPU VM, and concurrent - # isolated gateway workers make the short strict-agentic scenarios - # flaky, especially the approval-turn followthrough gate that expects - # a fast post-approval read within a 30s agent.wait timeout. + # The parity pack has 11 isolated scenario workers. It exercises a real + # gateway child plus mock model turns and subagents, so keep it serial in + # CI even on the larger runner. Concurrent isolated gateway workers make + # the short strict-agentic scenarios flaky, especially the approval-turn + # followthrough gate that expects a fast post-approval read within a 30s + # agent.wait timeout. QA_PARITY_CONCURRENCY: "1" OPENAI_API_KEY: "" ANTHROPIC_API_KEY: ""