Two tests that spawn isolated Cargo builds sit close to the nextest budget on
the Windows gate, and now carry a doubled timeout that nobody has justified
with a measurement.
harness_compiles_under_a_split_build_dir and
packaged_manifest_retains_build_script_sources each spawn a complete
isolated Cargo build. On run 33876121872 the first terminated at 300.081s with
the other 2,503 tests passing; the immediately preceding run finished it inside
the budget. That is marginal rather than broken.
The cause is a shape change rather than a code change. #664 moved the Windows
gate from a Namespace profile to a four-vCPU GitHub-hosted windows-latest
runner, whose compile throughput the 300s default in .config/nextest.toml was
never sized against.
The immediate fix, in #664, follows that file's own policy: a targeted override
with a written rationale rather than a retry, giving both tests twice the
budget, scoped to Windows so hang detection stays sharp on Ubicloud. That is
deliberately a bound, not an explanation.
What is worth knowing:
- How long does each actually take on
windows-latest, warm and cold? The
override hides the number; a measurement would say whether 600s is generous
or barely enough.
- Can the spawned build reuse anything? Each currently builds from scratch, and
the compiler cache the rest of the lane uses does not reach it.
- Is the split-build-dir harness compiling more than the assertion needs?
Close this by replacing the doubled budget with either a measured, tighter one
or a faster test, so the timeout stops being a guess.
Two tests that spawn isolated Cargo builds sit close to the nextest budget on
the Windows gate, and now carry a doubled timeout that nobody has justified
with a measurement.
harness_compiles_under_a_split_build_dirandpackaged_manifest_retains_build_script_sourceseach spawn a completeisolated Cargo build. On run 33876121872 the first terminated at 300.081s with
the other 2,503 tests passing; the immediately preceding run finished it inside
the budget. That is marginal rather than broken.
The cause is a shape change rather than a code change. #664 moved the Windows
gate from a Namespace profile to a four-vCPU GitHub-hosted
windows-latestrunner, whose compile throughput the 300s default in
.config/nextest.tomlwasnever sized against.
The immediate fix, in #664, follows that file's own policy: a targeted override
with a written rationale rather than a retry, giving both tests twice the
budget, scoped to Windows so hang detection stays sharp on Ubicloud. That is
deliberately a bound, not an explanation.
What is worth knowing:
windows-latest, warm and cold? Theoverride hides the number; a measurement would say whether 600s is generous
or barely enough.
the compiler cache the rest of the lane uses does not reach it.
Close this by replacing the doubled budget with either a measured, tighter one
or a faster test, so the timeout stops being a guess.