Publish prebuilt musl binary on v* tags#202
Merged
Merged
Conversation
On every tag matching `v*`, build a statically-linked `x86_64-unknown-linux-musl` binary, package it as a `.tar.gz`, and attach it to the auto-generated GitHub Release. The musl target makes the binary portable across any Linux x86_64 host with no glibc coupling. Subway's existing `docker.yml` already triggers on the same `v*` tag pattern, so cutting a tag now produces both a Docker image and a downloadable binary in one step.
xlc
approved these changes
May 19, 2026
rockbmb
added a commit
to rockbmb/runtimes
that referenced
this pull request
May 19, 2026
Subway started publishing a statically-linked `x86_64-unknown-linux-musl` binary on `v*` tags after AcalaNetwork/subway#202. Pulling it via `curl | tar -xz` is ~5s versus the previous ~4min `cargo install --git`, and removes the need for the rust toolchain install, the Swatinem cache layer, and the upstream-HEAD lookup step that fed the cache key. Also drops a `cat .github/env` step whose only purpose was to set `RUST_STABLE_VERSION` for the now-deleted toolchain install.
rockbmb
added a commit
to open-web3-stack/polkadot-ecosystem-tests
that referenced
this pull request
May 20, 2026
…pstream timeout (#622) * Install Subway from upstream `v0.1.0` musl release in `ci.yml` Switches `cargo install --git` to a `curl | tar -xz` of the released static binary (https://github.com/AcalaNetwork/subway/releases/tag/v0.1.0, published by AcalaNetwork/subway#202). Removes the Rust toolchain install, Subway-HEAD commit-hash lookup, and Swatinem cache layer that existed only to amortise the `cargo install` cost — none of them have any other consumer in this workflow. * Install Subway from upstream `v0.1.0` musl release in `update-known-good.yml` Same swap as the previous commit, applied to the periodic block-number update workflow. * Install Subway from upstream `v0.1.0` musl release in `update-snapshot.yml` Same swap as the previous two commits, applied to the snapshot-update workflow. * Fail Subway download fast on HTTP errors (`curl -f`) Without `-f`, an HTTP 4xx/5xx response (e.g. release deleted, GitHub degraded) leaves `curl` exiting zero with the error body on stdout, and the downstream `tar -xz` fails with a confusing "not in gzip format" message instead. Per review on PR #622. * Install Subway by extracting binary from `acala/subway:v0.1.1` Docker image The `v0.1.1` GitHub Release at AcalaNetwork/subway is missing its `x86_64-unknown-linux-musl.tar.gz` asset; the release workflow's `Build release binary` step failed (`cargo build --locked` mismatched the bumped `Cargo.toml` version), so the upload was skipped. The upstream tag still produces a working Docker image because `docker.yml` doesn't use `--locked`, so `acala/subway:v0.1.1` is the only working consumption path for v0.1.1. The image's binary lives at `/usr/local/bin/subway` (per Subway's Dockerfile); copying it out with `docker create` + `docker cp` lands in roughly the same wall time as the curl-and-untar path and unblocks consumption of PR #203's `request_timeout_seconds` config field. * Set Subway per-upstream `request_timeout_seconds` to 90s Subway's default per-upstream request timeout is 30s. With three Acala public RPC endpoints, heavy storage queries that take longer than 30s cause Subway to cycle through all three endpoints (~90s) before any single upstream has a chance to respond, and the test-side waiting client times out. `request_timeout_seconds` was added to `ClientConfig` in AcalaNetwork/subway#203 (Subway v0.1.1+). Setting it to 90 lets a single upstream attempt run long enough to complete those queries instead of being preempted by Subway's own per-endpoint clock. The companion exclusion of Acala tests in `vitest.config.mts` is intentionally left in place; this commit only restores Subway's ability to wait long enough. Lifting the exclusion is a separate verification step. * Re-enable Acala test suites `request_timeout_seconds: 90` on Subway's upstream client (added to `subway-template.yml` in the previous commit) gives Subway enough time per upstream attempt for Acala storage queries to land before the 30s default forced it to cycle endpoints. The exclusion added in PR #621 is no longer needed and is removed; the exclusion comment is narrowed to bifrostKusama, which still lacks a workable endpoint set.
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
2 participants
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.
Motivation
CI in polkadot-fellows/runtimes#1180 and the equivalent workflow in polkadot-ecosystem-tests currently runs
cargo install --git https://github.com/AcalaNetwork/subwayon every run, which rebuilds Subway from source. That adds roughly four minutes per job, and there are now six sharded jobs per network.Swatinem/rust-cachesoftens the cost, but the cache still misses when Subway's HEAD moves or GitHub evicts the entry under size pressure.A published binary would let those workflows replace
cargo installwith acurl | tar -xz, with no cache state on either side.docker.ymlalready triggers onv*tags, so this fits the existing release path: one tag, both a Docker image and a binary.Change
One new workflow file,
.github/workflows/release.yml, triggered on tags matchingv*. It builds a statically-linkedx86_64-unknown-linux-muslbinary using the toolchain pinned inrust-toolchain.toml, packages it as a.tar.gz, and attaches it to an auto-generated GitHub Release. No source changes.The musl target keeps the binary portable across any Linux x86_64 host without coupling to a specific glibc. Other targets (macOS, aarch64) are easy to add later if needed.
Notes
The first release needs a tag (e.g.
v0.1.0matching the currentCargo.tomlversion). After that, releases are tag-and-push.