Repository navigation
Release standalone tsunami-serve binaries - #3
Merged
Merged
Conversation
The MCP server is a standalone Rust binary, but there is no way to get one without a Rust toolchain: release.yml builds Python wheels only, and installing the wheel drags in a Python environment to run a server that does not need it. Anything that wants to pin the server -- a build system, a container image, a bare machine -- has to build from source. Add a `binaries` job that builds tsunami-serve for macOS and Linux on both architectures and uploads them to the GitHub release. Linux targets musl and links statically, so the binary has no glibc floor and runs on distroless and immutable images as well as on a distro. Two supporting changes: - Commit Cargo.lock. A workspace that ships a binary should have one, and `cargo build --locked` in the release job is what makes a tagged build reproducible rather than resolved afresh at release time. - Give tsunami-serve a `--version`. clap does not derive one unless asked, and a tool that cannot report its own version is one whose pin cannot be checked.
zarubaf
added a commit
to silicon-org/foundry
that referenced
this pull request
Aug 20, 2026
Waveform query engine the debugging agents drive over MCP. Pinned like every other CLI here rather than built in the graph: it is a tool people and agents type at, not something a build action invokes. Upstream shipped no binaries until zarubaf/tsunami#3; the Linux builds are static musl, so the pin has no glibc floor and runs on the Talos workers as well as a laptop.
zarubaf
added a commit
to silicon-org/foundry
that referenced
this pull request
Aug 23, 2026
Waveform query engine the debugging agents drive over MCP. Pinned like every other CLI here rather than built in the graph: it is a tool people and agents type at, not something a build action invokes. Upstream shipped no binaries until zarubaf/tsunami#3; the Linux builds are static musl, so the pin has no glibc floor and runs on the Talos workers as well as a laptop.
zarubaf
added a commit
to silicon-org/foundry
that referenced
this pull request
Aug 23, 2026
Waveform query engine the debugging agents drive over MCP. Pinned like every other CLI here rather than built in the graph: it is a tool people and agents type at, not something a build action invokes. Upstream shipped no binaries until zarubaf/tsunami#3; the Linux builds are static musl, so the pin has no glibc floor and runs on the Talos workers as well as a laptop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The MCP server is a standalone Rust binary, but there is no way to get one without a Rust toolchain.
release.ymlbuilds Python wheels only, and installing the wheel drags in a Python environment to run a server that does not need it. Anything that wants to pin the server — a build system, a container image, a bare machine — has to build it from source.This came up pinning
tsunami-serveinto a hardware monorepo's Bazel toolchain, where every CLI is fetched at a version and verified by SHA-256. There was nothing to point at.What
A
binariesjob that buildstsunami-servefor macOS and Linux on both architectures and uploads them to the GitHub release:aarch64-apple-darwintsunami-serve-<tag>-darwin-arm64x86_64-apple-darwintsunami-serve-<tag>-darwin-x86_64x86_64-unknown-linux-musltsunami-serve-<tag>-linux-x86_64aarch64-unknown-linux-musltsunami-serve-<tag>-linux-arm64Linux targets musl and links statically, so the binary has no glibc floor — it runs on distroless and immutable images as well as on a distro. The dependency tree is 143 pure-Rust crates (
wellen,lz4_flex,miniz_oxide,fst-readerare all native Rust), so there is nothing that needs a C toolchain to cross.A separate
releasejob attaches them, deliberately not folded intopublish— a PyPI outage should not cost the binaries, and vice versa.Supporting changes
Cargo.lock. A workspace that ships a binary should have one, andcargo build --lockedin the release job is what makes a tagged build reproducible rather than resolved afresh whenever the tag happens to be pushed.tsunami-servea--version. clap does not derive one unless asked. A tool that cannot report its own version is a tool whose pin cannot be checked.Testing
cargo build --release --locked -p tsunami-servebuilds clean onaarch64-apple-darwin. The workflow YAML parses and the job graph isbuild, sdist, binaries, release, publish. The cross-compiled targets have not been exercised — they will run for real on the first tag push.🤖 Generated with Claude Code