Idea (future, not needed now)

Several of our Linux/amd64 runners are actually WSL2 instances on Windows hosts (e.g. DESKTOP-12GQBKK is the WSL2 side of the same PC whose native-Windows runner DESKTOP-01APN6V is offline). WSL2 can execute Windows .exe via interop and reach the host filesystem at /mnt/c. So a WSL2 runner could, in principle, act as a Windows runner by bridging to the host toolchain — giving native Windows CI without standing up a separate Windows runner or Windows containers.

Why it’s NOT needed for building our own binaries

We build the Windows anvil.exe by cross-compiling x86_64-pc-windows-msvc from Linux with cargo-xwin (downloads the MSVC CRT/SDK, links with clang/lld). That needs no Windows host, no interop, and no WSL awareness — WSL-vs-bare-Linux is irrelevant to a cross-compile. So the whole Windows-support build path (fangorn/anvil-cli#32, rebased) works without any of this.

This ticket is only about the other capability: running user CI jobs that declare runs_on: [windows] as real Windows processes on a WSL2 host, by bridging to the host — i.e. Windows CI execution, not building anvil.

What it would involve

• WSL detection in the runner: /proc/sys/kernel/osrelease or /proc/version contains microsoft/WSL; also WSL_DISTRO_NAME/WSL_INTEROP env. Detect at registration.
• Advertise a Windows capability for a WSL runner (e.g. self-report an extra windows-host label, or a wsl2 fact) so the scheduler can route runs_on: [windows] jobs to it — distinct from runs_on: [linux] which it already serves as its WSL Linux self.
• Host-bridge execution: run the job’s steps on the Windows side via interop — invoke powershell.exe/host toolchain, translate /mnt/c/... ↔ C:\..., set up the host environment (e.g. vcvarsall for MSVC). This is the fiddly part and why we’re deferring it.
• Config/flags: opt-in (--windows-host or auto from detection), since not every WSL runner’s host is provisioned for Windows builds (needs a Windows rust toolchain + MSVC on the host).

Tradeoffs vs. alternatives

• vs. cross-compile (what we’re doing now): cross-compile can’t run Windows tests, only build. Host-bridge could run real Windows test suites and exercise the SCM/service/process code on actual Windows — the fidelity cross-compile can’t give.
• vs. a dedicated native Windows runner (fangorn/anvil-cli#32’s original runs_on: [windows] + image: bare path): the bridge reuses an existing WSL runner instead of maintaining a separate Windows one, but at the cost of interop plumbing. Once #32’s cross-compiled anvil.exe exists, bringing DESKTOP-01APN6V online as a real Windows runner is the simpler route to Windows test execution — the bridge is only worth it if we want Windows CI on hosts where only WSL is provisioned.

Prereq

Blocked-by nothing, but only useful once there’s a working Windows anvil.exe (fangorn/anvil-cli#32, cross-compiled). Revisit if/when we want to run Windows CI jobs, not just ship Windows binaries.