ci: run checks in the merge queue and cap job runtimes - #848
Conversation
Adds a `merge_group` trigger to the Check and Test workflow so every job runs against the queue's assembled group, and a 20-minute timeout to each job. The merge_group trigger is a prerequisite for enabling a branch merge queue: GitHub evaluates merge_group workflows from the target branch, so the trigger must live on main before the queue can require these checks — otherwise queued PRs wait forever on checks that never start. The queue's required-check list is exactly these job names. The per-job timeout bounds the queue's blast radius: in a merge queue a hung check blocks every entry behind it until the check-response timeout evicts the group, so an infrastructure stall (e.g. a stalled apt mirror, already observed here) must fail fast instead of idling at GitHub's 6-hour default. sort-correctness already carried a cap on some branches; this makes the bound uniform across the workflow.
|
Note Reviews pausedUse the following commands to manage reviews:
Use the checkboxes below for quick actions:
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
|
@coderabbitai pause |
✅ Action performedReviews paused. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #848 +/- ##
=======================================
Coverage 94.46% 94.46%
=======================================
Files 187 187
Lines 115301 115301
=======================================
+ Hits 108921 108922 +1
+ Misses 6380 6379 -1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This branch was successfully deployed
1 participant
Groundwork for enabling a branch merge queue on
main(mirroring the ferro-hgvs setup). This is step 1 of 3: it lands the workflow changes the queue depends on, ahead of any ruleset change. No queue is enabled by this PR.What changes
merge_grouptrigger to the Check and Test workflow, so all 13 jobs run against each group the queue assembles.timeout-minutes: 20to every job in the workflow.Why the trigger has to land first
GitHub evaluates
merge_groupworkflows from the target branch (main), not from the PR sitting in the queue. So the trigger must already be onmainbefore the queue can require these checks — otherwise every queued PR would wait forever on checks that never start. The queue's required-check list will be exactly these job names.Why the timeouts
In a merge queue a hung check blocks every entry behind it until the check-response timeout evicts the whole group. An infrastructure stall — e.g. the stalled apt mirror already seen on the
sort-correctnessjob — must fail fast rather than idle at GitHub's 6-hour default. This makes the 20-minute bound uniform across the workflow; the healthy path completes in ~4 minutes, so it's ~5× headroom.Not in this PR
miri.ymlis intentionally left PR-only (it'spaths-filtered tofgumi-raw-bam; a required check that doesn't run on every group would deadlock the queue, so it stays off the required list).merge_queuerule) — step 2, in a follow-up once this is onmain.