ci: declare promotion overflow pool before caller activation
Leo: "FOR OUR NIGHTLIES ARE THEY END TO END ON OUR FLEET? WE CAN'T BE RELYING ON BLACKSMITH THAT CUTS OUT".
The fleet-first promotion caller in #30076 requires RUNNER_POOLS.promotion, but the existing scheduled variable reconciler reads declarations from main. Split that declaration out first so the normal ci-cloud-overflow-probe.yml / runner_pools.py writer can populate it before caller activation.
Declare only the already reviewed 2-vCPU then 4-vCPU Linux overflow set. The variable supplies the paid overflow choice; it does not choose an owned runner or authorize bypassing owned admission. #30076 accepts it only after the controller records a full 180-second no-start, or selects its exclusive admitted owned runner instead. This prerequisite changes no workflow, permissions, secrets, cancellation, or runner trust. The owned admission set remains unchanged.
Prior art: #30076 (this split carries its existing declaration), #30340 (preserves the smaller Linux pool), #30164 (preserves structured runner validation). The wt prior-art GitHub query was unsupported by this VM broker; open/merged topic searches and these PRs were read manually.
Validation: runner-set policy 6 tests pass; runner-pools 36/37 pass. The single test_a_macos_only_overflow_record_does_not_freeze_linux_runner_on_a_dead_member failure (expects 16 vCPU, gets 4 vCPU) reproduces with main's exact runners.json and unchanged test/scripts, so is a base fixture regression. This declaration compiles nothing and uses no compiler cache.
| Performance | Before | After | Delta |
|---|---|---|---|
| Blacksmith minutes/day | Current routing | Unchanged by declaration alone | 0; caller activation is separate |
Agent session: agent session
š¤ Generated with Claude Code
Summary by CodeRabbit
- Chores
- Nightly promotion workflows can use additional runner capacity when the owned fleet has not started a job within 180 seconds. The added capacity includes 2-vCPU and 4-vCPU Ubuntu runners, available in that order.
- Runner-pool validation is deferred when the previous commit is unavailable or the runner-pool declaration has changed. Validation proceeds in a later workflow run. Application features and behavior remain unchanged.