Development record
check (macos-latest) runs on every pull request as well as on every merge-queue entry, and macOS is the account's scarcest runner, 5 jobs at once at a median 40 minutes each (8 queue runs, 2026-10-11). Between 03:36 and 08:40 on 2026-10-11 nothing merged: entries waiting for a macOS slot passed the queue's timeout and were removed. Every push already passed make preflight on a Mac, so the pull-request macOS run repeats a local run, and only the queue run tests the merged tree.
issueresolvedmajoriss-2610110938282654
check (macos-latest) runs on every pull request as well as on every merge-queue entry, and macOS is the account's scarcest runner, 5 jobs at once at a median 40 minutes each (8 queue runs, 2026-10-11). Between 03:36 and 08:40 on 2026-10-11 nothing merged: entries waiting for a macOS slot passed the queue's timeout and were removed. Every push already passed make preflight on a Mac, so the pull-request macOS run repeats a local run, and only the queue run tests the merged tree.
Frontmatter
| id | iss-2610110938282654 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2610110938282654-check-macos-latest-runs-on-every-pull.md
open on GitHub ↗ · commit history ↗
mentions2
- iss-2609012313465609Measured on 2026-09-01 with thirteen auto-merge pull requests in flight: each one pays two full CI cycles before it lands, and the macOS check job alone takes about 13 minutes (ubuntu 9). Cycle one: the pull request is armed, main moves, the strict up-to-date policy makes it BEHIND, the keep-current script updates the branch, and the full CI re-runs on the updated head before the pull request is CLEAN enough to enter the merge queue. Cycle two: the merge queue runs the full CI again on the merge group. Every merge moves main and knocks the not-yet-queued pull requests back to cycle one, so a batch of thirteen cost roughly twenty-six 13-minute cycles serialised in ALLGREEN groups, and a one-line record change waited an hour. The maintainer asks how to speed the gates up, for example by running them locally first. Directions, none adopted: (1) local-first is already built and not wired on every account: make preflight is the pre-push gate and .githooks/pre-push runs it, but core.hooksPath is unset on at least one active account, so nothing runs before a push; wire it at ahoy install (an owned ConfigChange) and record which accounts have it; note that a local pass shortens nothing on the forge, it only stops red pushes. (2) Run the full matrix once, in the queue: on the pull_request event run the fast lane only (format, record gates, ubuntu build and test) and keep the macOS leg, the race lane and the smoke harness for the merge_group event, which already runs everything; the CI classifier that stands macOS down for docs-only changes shows the seam exists. (3) Cache the Go build and test cache across runs (actions/setup-go cache keyed on go.sum) and check whether the macOS job's 13 minutes is test time or cold-build time. (4) Let the queue batch: min_entries_to_merge_wait_minutes is 0, so each pull request tends to get its own group; a short wait lets several share one CI run. (5) The strict policy is the multiplier and was kept on 2026-09-01 (iss-2609012202237613); revisit only with the duplicate-id gate argument answered.
- itd-2610110940216682Every change is checked in full once, on exactly what lands