ci: ship the Linux release as a static musl binary

[rollysys]

Problem

The x86_64-unknown-linux-gnu release tarball is built on ubuntu-22.04 and requires GLIBC_2.32+. On older-but-common distros it dies before printing anything:

auditui: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found

Hit firsthand installing onto an Ubuntu 20.04 / glibc 2.31 host.

Fix

Switch the Linux target to x86_64-unknown-linux-musl — a fully static binary with no glibc version dependency, runs on any x86_64 Linux.

This is cheap here because the deps are already static-friendly:

• rusqlite uses its bundled SQLite (compiles the amalgamation, no system libsqlite3),
• ureq uses rustls (no OpenSSL/native-tls).

So the only new build requirement is musl-tools (musl-gcc) to compile the bundled SQLite amalgamation and ring's C/asm.

• release.yml: Linux matrix target → musl, + a musl-tools install step (guarded on contains(matrix.target, 'musl')).
• install.sh: Linux x86_64 now resolves the …-linux-musl tarball.
• README(.zh): document the target as static / glibc-independent.

Verification

Triggered the workflow via workflow_dispatch on this branch (run 27144151007) — run succeeded:

• Build x86_64-unknown-linux-musl job: success (Install musl-tools ✓ → Build ✓ → Package ✓)
• Publish GitHub Release job: skipped (gated on a v* tag, so no release was cut)

The two "No files were found" artifact warnings in that run are a workflow_dispatch artifact: github.ref_name is the branch name (feat/linux-musl-release, contains /), which mangles the staging filename. On a real tag push ref_name is v0.1.x and the glob matches — the gnu builds have shipped this way for every prior release.

Once this and #27 merge and a new tag is cut, the dev host (glibc 2.31) can install via the normal one-liner — no more local source builds.

🤖 Generated with Claude Code

Co-Authored-By: Claude noreply@anthropic.com

[coderabbitai]

Warning

Review limit reached

@rollysys, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 55 minutes and 39 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: ca6157bc-983f-4377-ac08-fef79ab2ebb2

📥 Commits

Reviewing files that changed from the base of the PR and between 2879008 and 63d1833.

📒 Files selected for processing (4)

• .github/workflows/release.yml
• README.md
• README.zh.md
• install.sh

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/linux-musl-release

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}