CI: the decode-path job installs the repository's Rust pin, and byte equality runs on Windows again #643
Loading…
Reference in a new issue
No description provided.
Delete branch "ci/neural-pin-and-windows-byte-equality"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Two repairs to CI. Neither changes WAI's text or code.
The jpegai-decode-path job installs the repository's Rust pin
wai-neural-gates.yml'sjpegai-decode-pathjob installed Rust 1.98.0, the last 1.98.0 install in any workflow. The repository pins 1.99.1 inrust-toolchain.toml, so rustup installed 1.99.1 too, and the test compiled on it (run 19418, job 81788). The job already tested on the pin. The extra download was wasted, and the step's name was wrong.The step now bootstraps rustup with no default toolchain and runs a bare
rustup toolchain install, which reads the pin fromrust-toolchain.toml, as the wai-quantum member jobs do. It ends withrustup show active-toolchain, so the log names the toolchain cargo used. The tests are unchanged.Byte equality runs on Windows again
wai-byte-equality.yml'swindows-x86_64leg was taken out while that runner was down. The runner is back: a Windows job succeeded in run 19310, and the desktop app's Windows job passed in runs 19610 and 19807.pwshtwin with the same directories, floor, 32 MiB write-through probe and messages. Free space is what the volume leaves the runner's user. A write fails as infrastructure on the Win32 codes for a full or unwritable disk.relevantgate and is not a required status, as the other Windows legs are.Checked on the Windows runner host before this pull request
At
368a7f4, the commit this branch is based on:pwshdisk steps parse with PowerShell's own parser (0 errors).cargo test --release -- --nocaptureinwai/byte-exact-conformance, passes on Rust 1.99.1: 112 tests, 0 failed.The YAML parses, every
runs-onis a fleet label,wfstepsshows only the intended steps changed, and the workflow-concurrency and tests-in-CI checks pass.🤖 Generated with Claude Code
The leg was removed on 2026-09-30 while the Windows runner was offline. The runner is back: a `windows` job passed in run 19310 (job 81346), and the Studio's Windows desktop job passed in runs 19610 and 19807. - The matrix gets `- { os: windows, label: windows-x86_64 }` again, and the comment says x86_64 is held by linux-x86_64 and windows-x86_64. - The two disk steps run in bash, which on this host is the WSL stub. They stay unix-only. Each gets a pwsh form for Windows with the same directories, floor, write probe and messages: - the workspace, the runner's temporary directory, TEMP and the profile directory; - the free space the volume leaves the runner's user; - a 32 MiB write-through probe once per volume; - full-disk, write-protect, I/O device and quota errors named as infrastructure, by their Win32 codes. The after-failure form keys on the new step's id, disk_windows. - Both pwsh steps set the process execution policy to Bypass, as the Studio's Windows job does. The install and decode steps are unchanged. The Windows install step was already pwsh, and the bare `cargo test` step takes the host's pwsh default. No step bundles anything, so CI is not cleared. The Windows leg follows the repository's practice for a Windows job. It is not a required status, like wai-quantum-webgpu.yml's member-windows. Like the other legs, it runs only when the workflow's `relevant` gate answers true. If the runner goes offline again, the leg comes out of the matrix until the runner is back, as on 2026-09-30. Co-Authored-By: Claude Opus 5.5 <[email protected]>