Commit 5bf66df
committed
ci: give the Windows test job real timeout headroom (#717)
The `test` job ran with `timeout-minutes: 12` while a green Windows run
takes 11.8 minutes, leaving about 12 seconds of margin. Runner variance,
not the code under review, decided the outcome: PR #711's rerun finished
at 11.8min and passed, PR #653's was killed at 12.0min with `Test`
cancelled and every later step skipped.
That flakiness is expensive to review around, because `gh pr checks`
renders a cancelled job as `fail`. A red Windows check could mean a real
failure, a `cancel-in-progress` concurrency cancel, or this timeout, and
telling them apart requires reading `conclusion` from the check-runs API
plus per-job timings.
Measured on run 30459554635 (same suite, same commit):
ubuntu-latest 4.6 min
macos-latest 5.6 min
windows-latest 11.8 min
20 minutes keeps a green Windows run green with margin. It does not
address why Windows needs ~2.5x Linux on an identical suite; the comment
says so explicitly, because the ceiling has already been raised once
(8 -> 12) for this same reason and chasing it again is not a fix. The
`npm-global-smoke` job is untouched at 8 minutes: it completes in 1-2
minutes and was never near its limit.
Refs #7171 parent 12dbec3 commit 5bf66df
1 file changed
Lines changed: 11 additions & 3 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
48 | 48 | | |
49 | 49 | | |
50 | 50 | | |
51 | | - | |
52 | | - | |
53 | | - | |
| 51 | + | |
| 52 | + | |
| 53 | + | |
| 54 | + | |
| 55 | + | |
| 56 | + | |
| 57 | + | |
| 58 | + | |
| 59 | + | |
| 60 | + | |
| 61 | + | |
54 | 62 | | |
55 | 63 | | |
56 | 64 | | |
| |||
0 commit comments