A full Windows CI pass writes ~50 GB of cargo target output into the shared
C:\t (x64) / C:\t-a64 (arm64) scratch dirs on the intentionally-small (100 GB)
windows-amd64 runner. Left to accumulate across runs, that overflowed the disk
and every build died with "no space on device" (os error 112) — bytemuck_derive,
cc, bindgen, windows, tracing-subscriber, fs4 all failing mid-compile, taking
down pf-vdisplay/host builds.
ensure-windows-toolchain.ps1 already runs first in every Windows job, so reclaim
disk there before provisioning/building: call the runner-baked reclaimer
(unom/infra installs C:\Users\Public\act-runner\clean-runner-disk.ps1 + a
scheduled task) in threshold mode so THIS job starts with headroom regardless of
when that task last ran, and keep incremental caches warm when there's room. A
small inline fallback covers a runner not yet re-baked with the reclaimer. The
whole step is best-effort — a cleanup hiccup never fails the build.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The Windows CI runner (home-windows-runner-1, vmid 210) is now provisioned/owned by
unom/infra and can be rebuilt or joined by additional windows-amd64-labeled runners at
any time - a manually-dispatched provisioning workflow has no way to target a specific
runner instance, so it could land on an already-provisioned box instead of the one that
needed it. Replace windows-drivers-provision.yml / windows-punktfunk-provision.yml with
scripts/ci/ensure-windows-toolchain.ps1, a shared idempotent pre-flight (WDK/cargo-wdk,
FFmpeg, Inno Setup, ARM64 rustup target) that every Windows workflow now runs at job
start - a fast no-op once already provisioned, so any runner self-heals on first real use.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
enricobuehlerandClaude Opus 4.8