feat(ci): cross-compile a 64-bit Windows agent build #124
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/VA-122-windows-cross-compile-ci"
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?
Add a build-only Windows cross-compile on the existing Linux/openSUSE runner (no Windows runner) and upgrade the Windows-target compile check to clippy so the cfg(windows) modules stop bit-rotting. Scope is build + compile-check only: no signing, no publishing, no self-update wiring (deferred to VA-123/VA-124/VA-125).
New oci-build/release-windows.Dockerfile mirrors release.Dockerfile's export-to-scratch pattern but cross-compiles the vervain-agent binary for x86_64-pc-windows-gnu with mingw-w64. The mingw gcc cross-compiles rusqlite's bundled SQLCipher + vendored OpenSSL C sources from Linux, so the build stays --locked against the committed Cargo.lock. New .forgejo/workflows/build-windows.yml runs it on the same crates/**, Cargo.*, and toolchain paths as build-package.yml (plus its own Dockerfile and workflow path) and uploads vervain-agent.exe as a CI artifact rather than to the generic package.
Upgrade check.Dockerfile's Windows step from cargo check to cargo clippy --workspace --target x86_64-pc-windows-gnu -- --deny warnings so the Windows cfg paths are linted on every push/PR. That surfaced four pieces of Windows bit-rot behind Linux-only code: an unused tokio::process::Command import in vervain-agent-kvm, an unused std::path::Path import and never-constructed StatvfsStats struct in host/disks.rs, a never-used touch_slot_field in dispatch.rs, and an unused clap::ValueEnum import in main.rs. Each is now gated with cfg(target_os = "linux") so the Windows build is warning-clean, and the clippy gate mechanically fails if any reappear.
#VA-122