Distribute prebuilt autumn CLI binaries (curl-able install)

[madmax983]

Maintainer decision (2026-07-16): autumn should ship prebuilt autumn CLI binaries that users can fetch with curl, instead of cargo install being the only path — both for general onboarding DX ("right now you have to cargo install to even get autumn up and running, which is bad DX") and as the distribution mechanism for downstream CI consumers.

First consumer: #1931 (wire autumn a11y verify into generated-app CI) — a generated app's CI runner curls the pinned prebuilt binary rather than cargo-installing or extracting the scanner into the library.

Scope to design: build targets (Linux x86_64/aarch64 at minimum), where artifacts live (GitHub Releases per tag is the natural home), a stable "latest" URL + version-pinned URLs, checksum/signature story, and a curl | sh-style install script or documented one-liner.

[madmax983]

Scope note from implementing #2011: the release workflow ships macOS + Linux binaries — x86_64/aarch64 for both (Linux static-musl via cross, macOS native on macos-latest). Windows (x86_64-pc-windows-msvc) is deferred to a follow-up — the curl | sh installer doesn't serve Windows, so a Windows artifact plus a documented manual-download/PowerShell path is separable and tracked here for later.

---

Generated by Claude Code

[madmax983]

Scoping: x86_64-pc-windows-msvc for cli-release.yml — not a cheap add yet; here's why.

Assessed adding a Windows leg to the CLI release matrix. Recommendation: don't blind-add it to the matrix in this pass — verify on a real windows-latest runner first. Evidence below.

What's fine:

• autumn-cli is already structured for Windows: nix/libc are gated behind [target.'cfg(unix)'.dependencies], unix syscalls in src/process.rs / src/deploy/exec.rs are walled with #[cfg(unix)] + #[cfg(not(unix))] fallbacks, and there's an explicit #[cfg(target_os = "windows")] branch in which() plus a code comment warning about std::os::unix on Windows.
• Native cargo check -p autumn-cli (linux) is clean — the crate is healthy on the host.

The blocker found in-session: with the x86_64-pc-windows-msvc rust-std target installed, cargo check -p autumn-cli --target x86_64-pc-windows-msvc fails in a transitive C dependency, before Cargo ever type-checks autumn-cli's own Rust:

• aws-lc-sys v0.42 (the default rustls crypto provider aws-lc-rs, reached via rustls → reqwest/tokio-postgres-rustls/hyper-rustls) runs a build.rs that shells the host GNU cc to cross-compile aws-lc's bundled C/asm for the target:
  • cargo:warning=GNU compiler is not supported for this target
  • aws-lc/.../internal.h:552: error: unknown type name 'pthread_rwlock_t' / 'PTHREAD_RWLOCK_INITIALIZER' undeclared
  • → error occurred in cc-rs → aws-lc-sys build fails → graph aborts.

This is a cross-from-Linux toolchain limitation, not an autumn-cli source-portability bug. But because a native build-script artifact is a hard prerequisite for type-checking everything downstream, the check never reaches autumn-cli's own Rust — so source-level cfg(windows)/cfg(unix) correctness is unproven, not established.

Implications for a matrix leg:

1. The existing matrix builds Linux via cross and macOS natively. A Windows leg must be a native windows-latest runner (MSVC present), where aws-lc-sys can build — but it typically needs NASM on the runner (aws-lc-rs x86_64 assembly; e.g. ilammy/setup-nasm), or a switch of the rustls crypto backend to ring to drop the C/asm toolchain dependency entirely.
2. Adding an unverified leg is not cheap: with if-no-files-found: error and this crypto blocker, the binaries job would go red on every tagged release (fail-fast:false spares the other targets but the release still shows a failing job).
3. scripts/install.sh is POSIX-only — Windows users need a documented manual-download path (or a small install.ps1), deferred until a binary is actually produced.

Suggested path (small, staged): a throwaway workflow_dispatch trial job on windows-latest running cargo build -p autumn-cli --target x86_64-pc-windows-msvc (artifact-only, NOT attached to a release) to prove, in order: (a) aws-lc-sys builds on the runner (add setup-nasm or evaluate the ring provider), (b) autumn-cli's deploy/dev/process modules actually compile for Windows (the cfg(not(unix)) fallbacks exist but are currently unexercised), (c) the tarball/zip + checksum + versionless asset naming line up with the other targets. Only once that's green do we add the permanent matrix leg + a Windows install path. Not implementing in this pass.

---

Generated by Claude Code

[madmax983]

Correction to my comment above — the "source-level correctness unproven / aws-lc-sys blocker / would go red on every release" framing was wrong for a native Windows runner. Ground truth I confirmed after posting:

autumn-cli already compiles and passes cargo test --workspace on windows-latest today — it's in the Test matrix in .github/workflows/ci.yml ([ubuntu-latest, macos-latest, windows-latest]), unguarded. That build pulls in the full rustls → aws-lc-rs → aws-lc-sys crypto stack via feature unification, so aws-lc-sys already builds natively on windows-latest in CI. The failure I hit locally was purely a cross-from-Linux artifact — the host GNU cc can't cross-compile aws-lc's C/asm to the msvc target — not a real Windows incompatibility. The target is proven-buildable; only release packaging was missing.

Given that, I've implemented it rather than just scoping: #2033 (draft) adds a native windows-latest leg to cli-release.yml — x86_64-pc-windows-msvc, packaged as autumn-x86_64-pc-windows-msvc.zip + .sha256 (versionless naming preserved; fail-fast: false and the workflow_call/workflow_dispatch structure untouched), plus a scripts/install.ps1 and a README Windows install section (since install.sh is POSIX-only).

It's kept draft pending one windows-latest workflow_dispatch run of cli-release.yml (artifact-only, no release attach) to prove the zip/checksum packaging end to end — deferred right now only because GitHub Actions runners for this repo are badly starved today. Supersedes the packaging concerns in my previous comment.

---

Generated by Claude Code