Problem
The python-compat-smoke-build job has a 20-minute timeout shared across its OS matrix. On Windows this leaves little margin for GitHub runner setup variance and can cancel a healthy wheel build before any compatibility test runs.
This occurred on PR #359. The first Windows attempt spent about 6 minutes 45 seconds in disk cleanup, then was cancelled at the job timeout while Build pecos-rslib wheel was still compiling. There was no compiler or test failure. Rerunning the same commit passed without a code change.
Timing evidence
- Successful rerun: 15m58s total.
- Recent successful dev Windows jobs observed: approximately 14m33s to 17m29s total.
- The pecos-rslib wheel step alone commonly takes about 10 to 12 minutes.
- A few extra minutes in Free Disk Space (Windows) can therefore exhaust the current 20-minute budget.
Proposed hardening
Give the Windows matrix entry a 30-minute timeout, either by raising this job's timeout uniformly or by adding a matrix-specific timeout while retaining the current value for Ubuntu and macOS. Keep all existing build and compatibility coverage intact.
The disk-cleanup and cache strategy could be optimized separately, but increasing the timeout is the smallest reliable guard against runner variance.
Acceptance criteria
- A normally progressing Windows wheel build is not cancelled solely because runner preparation is slower than usual.
- Existing Windows wheel and downstream Python compatibility smoke coverage remains enabled.
- Genuine build and test failures continue to fail the job.
Problem
The python-compat-smoke-build job has a 20-minute timeout shared across its OS matrix. On Windows this leaves little margin for GitHub runner setup variance and can cancel a healthy wheel build before any compatibility test runs.
This occurred on PR #359. The first Windows attempt spent about 6 minutes 45 seconds in disk cleanup, then was cancelled at the job timeout while Build pecos-rslib wheel was still compiling. There was no compiler or test failure. Rerunning the same commit passed without a code change.
Timing evidence
Proposed hardening
Give the Windows matrix entry a 30-minute timeout, either by raising this job's timeout uniformly or by adding a matrix-specific timeout while retaining the current value for Ubuntu and macOS. Keep all existing build and compatibility coverage intact.
The disk-cleanup and cache strategy could be optimized separately, but increasing the timeout is the smallest reliable guard against runner variance.
Acceptance criteria