The hu release publishes hu-<version>-aarch64-unknown-linux-gnu.tar.gz. No job has ever executed the binary inside it.
Split out of #309, which is closed. G1, G2 and G3 are fixed; this is the residual.
What is and is not covered
|
Covered by |
| it cross-compiles |
hu cross-compiles for aarch64 Linux in ci.yml, on every pull request |
| it packages into a tarball |
the same job |
the binary starts, and hu plugin list finds its plugins |
nothing |
Both the CI job and the release workflow say so in their own comments:
Deliberately build-and-package only, no execution: qemu-user is expensive to provision (it killed a whole job while still realizing) and running the binary is a separate question from whether the release artifact can be produced.
The aarch64-linux tarball has no leg here because no GitHub-hosted runner can execute it; it stays unexercised by this workflow, deliberately and visibly.
The other two published targets do have an execution leg. smoke-test-binaries installs from the published release on ubuntu-latest and macos-latest, asserts hu --version, and asserts hu plugin list shows meter and monitor. aarch64-unknown-linux-gnu has no equivalent.
What could go wrong
hu links wasmtime, rusqlite's bundled C, ring's assembly and axum. A cross-compile proves each object builds for the target. It does not prove the linked binary starts, that wasmtime's JIT works there, or that plugin discovery resolves the right paths. An ARM Linux user would be the first to find out.
v0.2.0 shipped that tarball under exactly these conditions.
Why it stays open rather than fixed
Executing it needs either a runner that is natively aarch64, or qemu-user emulation. The comment above records that qemu was tried and abandoned because provisioning it killed a job.
Options, none costed:
- A GitHub-hosted arm64 Linux runner, if one is available to this repository.
- A self-hosted aarch64 runner.
- qemu-user, provisioned more carefully than the attempt that was abandoned.
- Accept it, and say so in
docs/tools/hu-install.md so an ARM user knows the tarball is unexercised.
Option 4 is the honest minimum and costs nothing. It is not currently done: the install docs list the aarch64 tarball beside the other two, with no caveat.
Not blocking
#309 called this "deliberately not prioritised", and nothing here changes that. It is filed so the limitation has a number rather than living in two code comments and a closed issue.
The
hurelease publisheshu-<version>-aarch64-unknown-linux-gnu.tar.gz. No job has ever executed the binary inside it.Split out of #309, which is closed. G1, G2 and G3 are fixed; this is the residual.
What is and is not covered
hu cross-compiles for aarch64 Linuxinci.yml, on every pull requesthu plugin listfinds its pluginsBoth the CI job and the release workflow say so in their own comments:
The other two published targets do have an execution leg.
smoke-test-binariesinstalls from the published release onubuntu-latestandmacos-latest, assertshu --version, and assertshu plugin listshowsmeterandmonitor.aarch64-unknown-linux-gnuhas no equivalent.What could go wrong
hulinks wasmtime, rusqlite's bundled C, ring's assembly and axum. A cross-compile proves each object builds for the target. It does not prove the linked binary starts, that wasmtime's JIT works there, or that plugin discovery resolves the right paths. An ARM Linux user would be the first to find out.v0.2.0shipped that tarball under exactly these conditions.Why it stays open rather than fixed
Executing it needs either a runner that is natively aarch64, or qemu-user emulation. The comment above records that qemu was tried and abandoned because provisioning it killed a job.
Options, none costed:
docs/tools/hu-install.mdso an ARM user knows the tarball is unexercised.Option 4 is the honest minimum and costs nothing. It is not currently done: the install docs list the aarch64 tarball beside the other two, with no caveat.
Not blocking
#309 called this "deliberately not prioritised", and nothing here changes that. It is filed so the limitation has a number rather than living in two code comments and a closed issue.