Repository navigation
Start merge-group validation ahead of the production deploy slot #6035
Description
🤖 Generated by the Agentic Engineer
Problem
Platform dispatches one merge-group build at a time. A PR can wait for hours before CI starts even when runners are available. On November 10, #6012 waited 6h 18m 45s for its group to start and merged 14m 14s later. A live sample showed one group running and 13 entries waiting.
Acceptance
- Let one additional group run validation while the first is active. Preserve all required checks and deploy only the first eligible candidate on the current main revision.
- Prove a stale, replaced, or out-of-order candidate cannot access production. Merge the production guard before changing the GitOps-owned ruleset.
- Verify the live ruleset and the first real overlap. Compare queue entry to merge for comparable PRs and record failures or retries separately.
Activity
chore: agent-claim #6035 nonce=d37d6a711896611a3d714cb3551271a5
devantler commentedon Nov 11, 2026
Delivery and native verification
Platform #6036 merged at 07:05:49 UTC on November 11. Its merge-group run passed the new admission wait, production deployment and required aggregate. Catalogue #893 merged at 07:28:48 UTC.
The live GitHub ruleset reported the change at 07:30:18 UTC. It allows two builds and one PR per merge, requires all entries to pass, and retains the 120-minute check response window. The declared manifest on main matches the native API.
Real validation overlapped. #6039's group started at 07:36:11 while #6040's group was active. #6040 merged at 07:53:29. #6039's admission wait completed at 07:53:35 and its production job started at 07:54:12. Both merged successfully.
Observed total queue time
The fixed baseline contains 21 successful merge groups from November 10, starting between 10:01:31 and 21:31:01 UTC. The post-change window covers completed groups after live activation through 13:49 UTC on November 11.
The comparison below includes PRs enqueued once and groups them by whether production deployment ran. Post-change PRs must also have entered the queue after activation. Every row joins the enqueue timeline, workflow creation, deployment result and actual merge time, and checks that the tested group SHA equals the merged SHA.
Median enqueue-to-group-start time fell from 2h 46m 06s to 52m 52s on the production path, and from 3h 26m 42s to 6m 24s when deployment was skipped. Median production group-start-to-merge time was 32m 06s before and 32m 25s after.
The post-change query found 22 completed successful groups. Four transitional PRs entered before activation and one PR was re-enqueued, leaving 17 in the comparison. Two re-enqueued baseline PRs were also excluded. Two groups were still running at observation and are excluded from completed samples. Traffic and backlog differed between the windows, which limits attribution to the setting alone.
The live setting, observed overlap, ordered production admission and lower total queue times satisfy this issue's acceptance criteria.