Feature Summary
cargo install sqwatch is the only documented install path, and it needs a Rust toolchain on the machine doing the install. Attach statically linked binaries to each GitHub Release so installing becomes one curl and untar.
Motivation / Use Case
HPC login nodes usually have no Rust toolchain, users usually cannot add one, and the glibc there is often several years old. Someone who reads "Requirements: Rust 1.90 or newer" stops there. Someone who tries cargo install on a login node either finds no cargo, or builds for four minutes on a shared node, which is the thing login-node etiquette exists to prevent.
A musl build sidesteps the glibc question entirely, and that matters more here than for most tools: RHEL 8 login nodes on glibc 2.28 are still common in production HPC, and a stock ubuntu-latest gnu build will not run on them.
Everything else a release needs is already there. The release workflow has version, changelog and semver gates and creates a GitHub Release with real notes. Only the artifacts are missing.
Proposed Solution
A build matrix in the release workflow, after the crates.io publish and before the Release step, covering x86_64-unknown-linux-musl and aarch64-unknown-linux-musl for login nodes and the two Apple targets for people driving it from a laptop. Upload sqwatch-<version>-<target>.tar.gz plus a SHA256SUMS through files: on the existing softprops/action-gh-release step. Nothing else in the workflow changes.
The musl build needs no cross and no container, just rustup target add and musl-tools on the runner, because nothing in the dependency set links against a system C library. Not worth reaching for cargo-dist at four targets, that is a twenty-line matrix.
Then rewrite the README Installation section so the binary download is first and cargo install second, and move "Rust 1.90 or newer" out of Requirements into a note about building from source.
Two follow-ons worth their own issues rather than being folded in here: add the musl target to CI so a broken static build fails on the PR rather than at release time, and note that CI is ubuntu-only today, so nothing currently proves the crate even compiles for macOS.
Feature Summary
cargo install sqwatchis the only documented install path, and it needs a Rust toolchain on the machine doing the install. Attach statically linked binaries to each GitHub Release so installing becomes one curl and untar.Motivation / Use Case
HPC login nodes usually have no Rust toolchain, users usually cannot add one, and the glibc there is often several years old. Someone who reads "Requirements: Rust 1.90 or newer" stops there. Someone who tries
cargo installon a login node either finds no cargo, or builds for four minutes on a shared node, which is the thing login-node etiquette exists to prevent.A musl build sidesteps the glibc question entirely, and that matters more here than for most tools: RHEL 8 login nodes on glibc 2.28 are still common in production HPC, and a stock
ubuntu-latestgnu build will not run on them.Everything else a release needs is already there. The release workflow has version, changelog and semver gates and creates a GitHub Release with real notes. Only the artifacts are missing.
Proposed Solution
A build matrix in the release workflow, after the crates.io publish and before the Release step, covering
x86_64-unknown-linux-muslandaarch64-unknown-linux-muslfor login nodes and the two Apple targets for people driving it from a laptop. Uploadsqwatch-<version>-<target>.tar.gzplus aSHA256SUMSthroughfiles:on the existingsoftprops/action-gh-releasestep. Nothing else in the workflow changes.The musl build needs no
crossand no container, justrustup target addandmusl-toolson the runner, because nothing in the dependency set links against a system C library. Not worth reaching forcargo-distat four targets, that is a twenty-line matrix.Then rewrite the README Installation section so the binary download is first and
cargo installsecond, and move "Rust 1.90 or newer" out of Requirements into a note about building from source.Two follow-ons worth their own issues rather than being folded in here: add the musl target to CI so a broken static build fails on the PR rather than at release time, and note that CI is ubuntu-only today, so nothing currently proves the crate even compiles for macOS.