Context
Today `.github/workflows/release.yml` ships 3 platform tarballs per `v*` tag:
| Target |
Runner |
Suffix |
| `x86_64-unknown-linux-gnu` |
`ubuntu-24.04` |
`linux-amd64` |
| `aarch64-unknown-linux-gnu` |
`ubuntu-24.04-arm` |
`linux-arm64` |
| `aarch64-apple-darwin` |
`macos-14` |
`darwin-arm64` |
For a CLI / builder tool the audience is more heterogeneous than for a server binary — developers, integrators, partner engineering teams. They sit on a wider range of OS+arch combinations than chain operators do, so the platform argument for cli is stronger.
| Project |
Linux x64 |
Linux arm64 |
macOS arm |
macOS Intel |
Linux musl |
Windows |
| foundry / forge |
✅ |
✅ |
✅ |
✅ |
✅ |
✅ |
| bat / ripgrep |
✅ |
✅ |
✅ |
✅ |
✅ |
✅ |
| ligate-cli (today) |
✅ |
✅ |
✅ |
❌ |
❌ |
❌ |
foundry/forge is the right peer for cli: cross-platform Rust developer tool used by integrators across the industry. We should converge on a similar matrix.
What this issue adds
Three additions to the matrix in `.github/workflows/release.yml`:
1. macOS Intel (`darwin-amd64`) — highest value of the three
```yaml
- target: x86_64-apple-darwin
runner: macos-13
archive_suffix: darwin-amd64
```
Audience: pre-2023 Intel MacBook developers. Still a real cohort (any 2018-2022 MBP). Shrinks every year but non-zero today. Without this they have to `cargo install --git` and wait 10-15 min for a cold-cache compile.
2. Windows amd64 (MSVC) — biggest new audience reach
```yaml
- target: x86_64-pc-windows-msvc
runner: windows-2022
archive_suffix: windows-amd64.exe
```
Audience: Windows developers, especially partner engineering teams outside crypto-native shops. Anyone integrating `ligate-cli` from a corporate Windows laptop into their backend tooling. Bigger latent audience than macOS Intel, since "Windows is my work laptop" is normal in many industries.
Note the `.exe` suffix on the archive name — Windows binaries need it. Worth confirming the archive structure handles `.tar.gz` vs `.zip` correctly for Windows users (most expect zip on Windows).
3. Linux amd64 + arm64 static (`musl`)
```yaml
Audience: CI users running cli inside Alpine / distroless containers (`ligate sign-attestation` from a GitHub Actions step, etc). Less critical than the OS-coverage adds above but cheap to include.
Cost analysis
- macOS Intel: `macos-13` runner, 10× minute multiplier. ~5-10 min build × 10 = added cost
- Windows MSVC: `windows-2022`, 2× minute multiplier. ~5-10 min build × 2 = added cost
- Linux musl: same Ubuntu runners, ~5-10 min build × 1 = added cost
Bounded by release cadence (~1 release / week initially). All matrix-parallelizable so wall-clock release time bounded by slowest single platform.
Why this is post-launch polish
The current Tier-1 coverage (linux glibc + macOS arm) handles 80%+ of CLI users. This issue is for converging on the foundry / ripgrep platform expectation, not for unblocking adoption. Targeted milestone: post-launch polish, not v0.x.
Implementation notes
- All matrix entries above add directly into the existing `build` job in `release.yml`
- Windows builds: confirm `.zip` vs `.tar.gz` archive convention; Windows users typically expect zip
- musl targets need `apt install musl-tools` before `cargo build --target ...`
- Cross-platform binary naming: settle on whether to use `ligate.exe` vs `ligate` inside the Windows archive
Related
- ligate-chain has the same issue, filed alongside this one
Context
Today `.github/workflows/release.yml` ships 3 platform tarballs per `v*` tag:
For a CLI / builder tool the audience is more heterogeneous than for a server binary — developers, integrators, partner engineering teams. They sit on a wider range of OS+arch combinations than chain operators do, so the platform argument for cli is stronger.
foundry/forge is the right peer for cli: cross-platform Rust developer tool used by integrators across the industry. We should converge on a similar matrix.
What this issue adds
Three additions to the matrix in `.github/workflows/release.yml`:
1. macOS Intel (`darwin-amd64`) — highest value of the three
```yaml
runner: macos-13
archive_suffix: darwin-amd64
```
Audience: pre-2023 Intel MacBook developers. Still a real cohort (any 2018-2022 MBP). Shrinks every year but non-zero today. Without this they have to `cargo install --git` and wait 10-15 min for a cold-cache compile.
2. Windows amd64 (MSVC) — biggest new audience reach
```yaml
runner: windows-2022
archive_suffix: windows-amd64.exe
```
Audience: Windows developers, especially partner engineering teams outside crypto-native shops. Anyone integrating `ligate-cli` from a corporate Windows laptop into their backend tooling. Bigger latent audience than macOS Intel, since "Windows is my work laptop" is normal in many industries.
Note the `.exe` suffix on the archive name — Windows binaries need it. Worth confirming the archive structure handles `.tar.gz` vs `.zip` correctly for Windows users (most expect zip on Windows).
3. Linux amd64 + arm64 static (`musl`)
```yaml
target: x86_64-unknown-linux-musl
runner: ubuntu-24.04
archive_suffix: linux-amd64-musl
target: aarch64-unknown-linux-musl
runner: ubuntu-24.04-arm
archive_suffix: linux-arm64-musl
```
Audience: CI users running cli inside Alpine / distroless containers (`ligate sign-attestation` from a GitHub Actions step, etc). Less critical than the OS-coverage adds above but cheap to include.
Cost analysis
Bounded by release cadence (~1 release / week initially). All matrix-parallelizable so wall-clock release time bounded by slowest single platform.
Why this is post-launch polish
The current Tier-1 coverage (linux glibc + macOS arm) handles 80%+ of CLI users. This issue is for converging on the foundry / ripgrep platform expectation, not for unblocking adoption. Targeted milestone: post-launch polish, not v0.x.
Implementation notes
Related