feat(release): build pixi-riscv64gc-unknown-linux-musl

[pavelzw]

Description

Adds riscv64gc-unknown-linux-musl to the release matrix, alongside the existing glibc build. Closes #6903.

To answer the question in the issue — nothing fundamental was missing, the target just was never added. Rust ships a tier-2 riscv64gc-unknown-linux-musl std, and since the other Linux musl targets already cross-compile with cargo-zigbuild, this one needs no new tooling (there is no gcc-riscv64-linux-musl in apt, so zigbuild is the practical route).

The release ships both riscv64 pixi builds (gnu and musl). In the Rust code, riscv64 now behaves like x86_64 and aarch64 — no branching on libc:

• Trampoline. pixi global embeds a trampoline binary per target via include_bytes!. riscv64 now always embeds the musl one, matching x86_64/aarch64. The musl trampoline is statically linked so it runs on glibc riscv64 hosts too, which makes the gnu trampoline dead weight — it is no longer built, and the committed binary is dropped.
• self-update. default_archive_name() returned None for riscv64, so pixi self-update was already broken there on the existing gnu build. It now resolves to the musl archive.

Ordering caveat (why this is still a draft)

crates/pixi_global/src/trampoline.rs references pixi-trampoline-riscv64gc-unknown-linux-musl.zst, which does not exist in the repo yet — trampoline binaries are committed by the separate trampoline.yaml workflow. So the new CI job will fail on include_bytes! until that workflow runs on trampoline-build-branch and its commit is merged. Same ordering the loong64 support PR (#4163) had, where the cfg landed before the binary.

Happy to split this into two PRs (trampoline first, then target) if that's preferable.

install.sh left alone, deliberately

#6143 pinned riscv64 to unknown-linux-gnu in install.sh because no musl asset existed. Tempting to flip it back now, but docs.yml republishes install.sh from main on every docs deploy, so flipping it before a release carries the musl asset would 404 every riscv64 install. It should be flipped in a follow-up after the first release that includes the new asset — and even then PIXI_VERSION=<older> on riscv64 would need the gnu name. The gnu build is kept, so nothing regresses either way.

How Has This Been Tested?

Not built for the new target locally — no riscv64 musl sysroot here, so that part relies on CI. Locally verified: cargo check -p pixi_global -p pixi_cli passes on the host after the trampoline/self-update changes, all three workflow YAMLs parse, and sh -n install/install.sh passes. The new build binary | linux riscv64gc musl CI job builds the workspace for the target on PRs (the existing gnu job is main-only) — but see the ordering caveat above for why it won't go green as-is.

AI Disclosure

• This PR contains AI-generated content.
  • I have tested any AI-generated content in my PR.
  • I take responsibility for any AI-generated content in my PR.

Tools: Claude Code (Claude Opus 5)

Checklist:

• I have performed a self-review of my own code

[pavelzw]

Suggested change

	// riscv64 is released for both glibc and musl; stay on the libc the
	// running binary was built against.
	if cfg!(target_env = "musl") {
	Some("pixi-riscv64gc-unknown-linux-musl.tar.gz".to_string())
	} else {
	Some("pixi-riscv64gc-unknown-linux-gnu.tar.gz".to_string())
	}
	Some("pixi-riscv64gc-unknown-linux-musl.tar.gz".to_string())

[pavelzw]

Suggested change

	#[cfg(target_env = "gnu")]
	const TRAMPOLINE_BIN: &[u8] =
	include_bytes!("../../../trampoline/binaries/pixi-trampoline-riscv64gc-unknown-linux-gnu.zst");
	#[cfg(target_arch = "riscv64")]
	#[cfg(target_os = "linux")]
	#[cfg(target_env = "musl")]
	const TRAMPOLINE_BIN: &[u8] =
	include_bytes!("../../../trampoline/binaries/pixi-trampoline-riscv64gc-unknown-linux-musl.zst");
	const TRAMPOLINE_BIN: &[u8] =
	include_bytes!("../../../trampoline/binaries/pixi-trampoline-riscv64gc-unknown-linux-musl.zst");