Symptom
Desktop Swift Release Compile is running at roughly 95% of its 60-minute job cap. When it exceeds the cap it is cancelled, and because the required check Desktop Swift Build & Tests asserts RELEASE_RESULT = success, the cancellation fails that required check too.
The failure shape is misleading. The static and test lanes pass — VERIFY_RESULT: success — while the gate fails on RELEASE_RESULT: cancelled, so it reads as a test failure when it is a budget overrun.
Measurements
Four consecutive runs on the same branch (#11864), same command:
| head |
duration |
result |
d57a905e |
51m00s |
green |
5e6d07e5 |
60m46s |
cancelled at the cap |
35e43d5d |
56m55s |
green |
445f83a5 |
~56.8m |
green |
35e43d5d is compile-identical to d57a905e — the delta between them is comment lines and one changelog string — and it still ran ~6 minutes slower. So the growth is not coming from the diffs.
The same cancellation was hit independently on #12664.
Why it is not visible
The lane is skipped on branches that do not touch desktop Swift, so main's own runs mostly report it as skipped and the drift never shows up there. It only surfaces on desktop-touching PRs, one at a time, as an apparently unrelated red check.
Concurrency may be a contributing factor and I have not isolated it: at the time of filing, four desktop branches were executing this lane simultaneously.
Impact
On current headroom, ordinary variance is enough to cancel a required check on any desktop-touching branch. The contributor-visible result is a red required check with a green test lane, which costs a diagnosis cycle each time — it cost one on #11864, where the cancellation was initially attributed to a three-line source change that turned out to be unrelated.
Not filing a fix
CODEOWNERS routes /.github/workflows/** to a single owner, so a contributor cannot change the cap or split the lane. Raising the cap and splitting the release compile from the UserNotifications release-mode test step are both plausible directions, but which one is right depends on why the lane is growing, which I have not established.
Filed from the measurements above rather than guessed at; happy to gather more data on request.
Symptom
Desktop Swift Release Compileis running at roughly 95% of its 60-minute job cap. When it exceeds the cap it is cancelled, and because the required checkDesktop Swift Build & TestsassertsRELEASE_RESULT = success, the cancellation fails that required check too.The failure shape is misleading. The static and test lanes pass —
VERIFY_RESULT: success— while the gate fails onRELEASE_RESULT: cancelled, so it reads as a test failure when it is a budget overrun.Measurements
Four consecutive runs on the same branch (#11864), same command:
d57a905e5e6d07e535e43d5d445f83a535e43d5dis compile-identical tod57a905e— the delta between them is comment lines and one changelog string — and it still ran ~6 minutes slower. So the growth is not coming from the diffs.The same cancellation was hit independently on #12664.
Why it is not visible
The lane is skipped on branches that do not touch desktop Swift, so
main's own runs mostly report it asskippedand the drift never shows up there. It only surfaces on desktop-touching PRs, one at a time, as an apparently unrelated red check.Concurrency may be a contributing factor and I have not isolated it: at the time of filing, four desktop branches were executing this lane simultaneously.
Impact
On current headroom, ordinary variance is enough to cancel a required check on any desktop-touching branch. The contributor-visible result is a red required check with a green test lane, which costs a diagnosis cycle each time — it cost one on #11864, where the cancellation was initially attributed to a three-line source change that turned out to be unrelated.
Not filing a fix
CODEOWNERSroutes/.github/workflows/**to a single owner, so a contributor cannot change the cap or split the lane. Raising the cap and splitting the release compile from the UserNotifications release-mode test step are both plausible directions, but which one is right depends on why the lane is growing, which I have not established.Filed from the measurements above rather than guessed at; happy to gather more data on request.