fix(ci): raise nightly Windows build timeout to 180m (nightly red since 26.7.49) - #645
Merged
Merged
Conversation
The nightly build job was cancelled mid-compile at the 90-minute cap in run 30190411454 (2026-07-26, sha 8d6aaed, v26.7.49) — the first full nightly after PRs #641 and #643 merged. Root cause: the "Run tests" step (cargo test --release --locked) must compile every integration test binary in tests/ in release mode with debug info. #641 and #643 added 26 new test files (112 total), and the step went from ~27 min in run 29805777509 (v26.7.47) to over 70 min without reaching "Finished". Nothing is hung — the last log line is a normal Compiling entry and no test ever ran. The failure is self-perpetuating: a cancelled job skips its cache-save post step, so the enlarged release test binaries never entered the rust-cache entry and each following nightly restarts cold and times out again. This raises only the job timeout, mirroring the 60 -> 90 bump in PR #618. No source, dependency, or language behavior changes, so no TestPrograms impact.
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe Windows nightly build job timeout increases from 90 to 180 minutes, with comments explaining test compilation growth and cache repopulation after cancellations. ChangesNightly workflow configuration
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the Windows-only nightly GitHub Actions workflow to prevent the nightly pipeline from being cancelled due to the job-level timeout during long release-mode test compilation on windows-latest.
Changes:
- Increased the
Build WFL for Windowsjob timeout from 90 minutes to 180 minutes. - Added an in-file rationale comment explaining why the higher timeout is needed (and why it should help the cache warm back up).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+126
to
+137
| # `cargo test --release` here compiles EVERY integration test binary in | ||
| # tests/ (112 of them as of 26.7.49) against the full dependency graph, in | ||
| # release mode with `[profile.release] debug = true` — so each one also links | ||
| # a large PDB on the MSVC target. PRs #641/#643 added 26 new test files, | ||
| # which pushed this single step from ~27 min (26.7.47, run 29805777509) to | ||
| # over 70 min without finishing, and the job hit the previous 90-minute cap | ||
| # (run 30190411454, cancelled mid-compile). Because a cancelled job never | ||
| # runs its cache-save post step, the enlarged test binaries never landed in | ||
| # the Swatinem/rust-cache entry, so every following nightly restarted from | ||
| # the same cold state and timed out again. 180 min gives the first post-#641 | ||
| # nightly room to finish and repopulate the cache; warm runs stay far below | ||
| # it. Previous bump was 60 -> 90 in PR #618 for the same class of growth. |
23 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What was broken
The Nightly Build is red. Run 30190411454 (2026-07-26 06:03 UTC, sha
8d6aaed2= v26.7.49) was cancelled, not failed: theBuild WFL for Windowsjob hit itstimeout-minutes: 90cap at 07:34:05 and GitHub killed it.Run testswas cancelled mid-step;Run LSP Tests, the VS Code extension build, the WiX MSI and the wholereleasejob were skipped, so no nightly release was published for 2026-07-26.This was the first full nightly after PRs #641 and #643 merged. The 07-22 → 07-25 nightlies were all no-change skips on
9a8e0cca, so the cost increase was invisible until today.Root cause
The
Run testsstep runscargo test --release --locked, which compiles every integration test binary intests/against the full dependency graph — in release mode, and with[profile.release] debug = true, so each binary also links a large PDB onx86_64-pc-windows-msvc.PRs #641/#643 added 26 new test files (
tests/is now 112 targets) plus new deps (tokio-tungstenite0.30,rcgen,yasna,pem). Measured against the last full nightly:Run testsFinishedNothing is hung. The final log line is an ordinary
Compiling tokio-tungstenite v0.30.0at 06:26:00, and noFinished/Runningline for the test profile ever appears — the step was still in codegen/link when the cap fired.Worth flagging: the failure is self-perpetuating. A cancelled job does not run its cache-save post step (
Post Cache Cargo registry + target dirisskippedin this run), so the enlarged release test binaries never entered theSwatinem/rust-cacheentry. Every subsequent nightly restarts from the same pre-#641 cache and times out at the same point. The nightly will stay red until the cap is raised once and the cache repopulates.The fix
One line plus a rationale comment:
timeout-minutes: 90→180on thebuildjob. This mirrors PR #618, which raised the same cap 60 → 90 for the same class of growth.180 min gives the first post-#641 nightly room to finish and save its cache; warm runs should return to well under an hour once it does.
Verification
jobs.build.timeout-minutes == 180).Cargo.lock, or.build_meta.jsonchange — CI-config only, so there is no language-behavior surface and noTestPrograms/impact. Backward compatibility is untouched.windows-latest, and this triage environment is aarch64 Linux with no Rust toolchain. The diagnosis rests on the run logs and the step-level timing comparison above, which are unambiguous about where the time went.ci.ymlwill not validate this change either — its integration lanes compile the test binaries in debug (14 min on Windows today), which is exactly whyci.ymlstayed green while the nightly went red.workflow_dispatchrun ofnightly.ymlfrom this branch) after merge.Recommended follow-ups (not in this PR)
Run testsinto its own parallel job, would cut wall-clock more durably than raising the cap a third time.ci.ymlnever exercises release-mode Windows test compilation, so this class of regression can only ever surface at 06:00 UTC.Automated triage PR from the WFL repo warden — opened for a human to review and merge; I have not merged it.
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.Summary by CodeRabbit