Repository navigation
ci: run Windows tests in release and report every failure - #508
Merged
Merged
Conversation
The wall-time and scale tests are calibrated for optimized binaries; the debug build on the Windows runner overran them (--budget 10 took 24.1s against a 22.5s limit, and the 50k-file scale test ran out of time), so main failed on four pushes, each on a different test because cargo test stopped at the first failing binary.
There was a problem hiding this comment.
inspect review
Triage: 1 entities analyzed | 0 critical, 0 high, 1 medium, 0 low
Verdict: standard_review
Findings (0)
Reviewed by inspect | Entity-level triage found 0 high-risk changes
rs545837
added a commit
that referenced
this pull request
Oct 6, 2026
…t to Unix (#509) Follow-up to #508. With release builds and `--no-fail-fast`, the Windows run showed exactly two remaining failures out of the full suite. ## cli_simplify goldens The fixture commits with `GIT_AUTHOR_DATE=@1700000000` and no offset, so git stamps the machine's local timezone into each commit and the SHAs change with it. The goldens were generated at +0530, so the test only passed on machines in that zone. It failed on the UTC Windows runner and on a US-timezone Mac. The fixture now pins `+0530`, which matches the existing goldens without regenerating them. Golden files are also read with CRLF normalized, since a Windows checkout converts them. Verified locally: 15/15 pass with TZ unset (America/Los_Angeles), TZ=UTC and TZ=America/New_York. ## arch_diff_scale The test exists to hold arch-diff under 1 GB on a 50k-file repo, and it reads peak memory with `ps`, which Windows does not have (the run reported `peak 0 MB`). Generating the 50k files also took 465s on the Windows filesystem. Gated to `#[cfg(unix)]`, matching how the memory-budget test in arch_diff_review was gated.
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.
Why
Windows CI has failed on the last four pushes to main, each time on a different test:
arch_diff_budget:--budget 10took 24.1s against a 22.5s limitarch_diff_scale: the 50k-file repo test ran 890s and exhausted its time budgetarch_diff_review(since gated to Linux/macOS) andaccessor_cli(stack overflow, fixed by the 16 MB stack change)This workflow is the only CI job that runs the sem-core and sem-cli suites, and it ran them as a debug build. The newer wall-time and scale tests are calibrated for optimized binaries, so debug on the Windows runner overruns them.
cargo testalso stops at the first failing test binary, which is why each run surfaced a different test.Change
--release --target x86_64-pc-windows-msvc, the build step's target, so its artifacts are reused.--no-fail-fastreports every failing binary at once.Verification
This PR's own Windows run is the check. If anything still fails in release it will show up all at once here.