From cbd71ff3ee9ee644517cba140a02f5b57e60432b Mon Sep 17 00:00:00 2001 From: S'Bussiso Dube <80188685+Sbussiso@users.noreply.github.com> Date: Sat, 12 Sep 2026 21:26:09 -0700 Subject: [PATCH] Compile the Windows half of the tree in CI MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Everything under cfg(target_os = "windows") was invisible to CI: src/service.rs — the entire Windows Service entry point — plus the windows-service and tracing-appender dependencies and every Windows branch in the platform modules. test.yml runs ubuntu-only, so the only thing that ever compiled that code was release.yml, on a tag, after the decision to ship had already been made. The gap had teeth. windows-service 0.7 -> 0.8 (#25) could not be reviewed at all: ubuntu CI reported green without compiling a line of what the bump affects, and cross-compiling to x86_64-pc-windows-msvc fails locally in ring's build script with no MSVC toolchain available. For a binary that installs onto customers' own machines as a Windows Service, release time is the wrong moment to discover that. Adds a `windows` job on windows-latest running build + clippy. A full build rather than `check`, because linking is part of what can break when windows-service resolves Service Control Manager entry points — a check would type-check those and never link them. No `cargo test` on Windows: `--all-targets` already type-checks the test code, which is what catches a Windows-only compile regression. Running the suite there means triaging tests that assume POSIX paths and a present ffmpeg — worth doing, not worth coupling to this. Also drops number_prefix from the cargo-audit comment's list of unmaintained crates; indicatif 0.18 stopped depending on it in #35. Co-Authored-By: Claude Opus 5 --- .github/workflows/test.yml | 66 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 63 insertions(+), 3 deletions(-) diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index 86e6a62..277b544 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -9,6 +9,24 @@ name: Test # Deploy/release automation deliberately stays in release.yml (tag # triggered): cutting a release should remain an explicit act, not a # side effect of merging. +# +# TWO JOBS, because one runner cannot see all of this code. The `test` +# job is ubuntu and covers the bulk; the `windows` job exists because +# everything under `cfg(target_os = "windows")` is INVISIBLE to it — +# `src/service.rs` (the whole Windows Service entry point), the +# `windows-service` and `tracing-appender` dependencies, and every +# Windows branch in the platform modules. None of that was compiled by +# any CI job until 2026-09-12; the only thing that ever built it was +# release.yml, on a tag, after the decision to ship had already been +# made. +# +# That gap had teeth. The windows-service 0.7 -> 0.8 bump (#25) could +# not be reviewed: ubuntu CI reported green without compiling a line of +# the code the bump affects, and cross-compiling to +# x86_64-pc-windows-msvc fails locally in ring's build script without an +# MSVC toolchain. For a binary that installs onto customers' own +# machines as a Windows Service, "we'll find out at release" is the +# wrong moment to find out. on: push: @@ -72,10 +90,52 @@ jobs: # the gate is on. # # `cargo audit` also reports `unmaintained` warnings — currently - # fxhash and number_prefix. Those are not vulnerabilities and do not - # fail the build; `--deny warnings` is deliberately NOT set, for the - # same reason clippy doesn't run with -D warnings here. + # fxhash alone. (number_prefix was the other one until indicatif + # 0.18 stopped depending on it.) Those are not vulnerabilities and + # do not fail the build; `--deny warnings` is deliberately NOT set, + # for the same reason clippy doesn't run with -D warnings here. - name: Security advisories (cargo audit) run: | cargo install cargo-audit --locked || true cargo audit + + # The Windows half of the tree. See the header comment for why this is + # a separate job rather than a matrix entry on the one above: it runs a + # different, smaller set of steps, because its job is to compile code + # ubuntu cannot see, not to re-run the whole suite on a second OS. + windows: + name: Windows build + clippy + runs-on: windows-latest + steps: + - uses: actions/checkout@v7 + + - name: Install Rust toolchain + uses: dtolnay/rust-toolchain@stable + with: + components: clippy + + - name: Cache cargo registry + target + uses: Swatinem/rust-cache@v2 + + # A full `build`, not just `check`. For a binary that registers + # with the Windows Service Control Manager, linking is part of what + # can break — `windows-service` resolves SCM entry points, and a + # `check` would type-check them and never try to link them. + # + # No system-dependency step: the MSVC toolchain on windows-latest + # already covers what rusqlite's bundled SQLite and the zip crate's + # bzip2-sys need to compile. No ffmpeg either — the encoder tests + # that probe for it aren't run here (see below). + - name: Build + run: cargo build --locked + + - name: Clippy + run: cargo clippy --all-targets --locked + + # Deliberately NO `cargo test` here. `--all-targets` above already + # type-checks the test code, which is what catches a Windows-only + # compile regression. Actually running the suite on Windows is a + # larger question than this job answers — several tests assume + # POSIX paths and a present ffmpeg, so turning them on means + # triaging real failures that have nothing to do with the change + # being reviewed. Worth doing; not worth coupling to this.