ci: the workloads checked on every other system a release is built for #261

Merged
admin merged 2 commits from ci/every-target into dev 2026-10-14 23:23:58 +00:00
Owner

What and why

Releases build sisyphusd for RISC-V, 32-bit ARM, the BSDs and Android too, but none of those builds was ever run. GitHub has no runners for them, so this PR runs the known-answer workloads (the tests whose answers must match on any machine) in the next best place:

Target Where it runs
linux/riscv64, linux/arm (v7), linux/ppc64le, linux/s390x, linux/loong64 under qemu-user (the qemu-user package; Ubuntu 26.04 no longer has qemu-user-static) on ubuntu-26.04
linux/386 natively on ubuntu-26.04 (an x86-64 kernel runs 32-bit x86)
android/arm64 on ubuntu-26.04-arm, loaded by Linux's own loader: the test binary names Android's /system/bin/linker64 but links no libraries
freebsd/amd64, openbsd/amd64, netbsd/amd64 in a virtual machine of each (vmactions)

s390x is big-endian, so it checks that no answer, and no CID, depends on byte order.

Releases gain linux/386, linux/ppc64le, linux/s390x, linux/loong64 and openbsd/arm64. All of them build the whole daemon without cgo. netbsd/arm64 is the one target a dependency refuses. The daemon guide's table and the README say what runs where.

All ten jobs pass on this PR's last run.

How it was checked

  • Locally: go test -c ./packages/runtime succeeds for all eleven targets (the seven new here and four more), and go build ./apps/sisyphusd for each new release target.
  • This PR's CI runs each new job.
## What and why Releases build `sisyphusd` for RISC-V, 32-bit ARM, the BSDs and Android too, but none of those builds was ever run. GitHub has no runners for them, so this PR runs the known-answer workloads (the tests whose answers must match on any machine) in the next best place: | Target | Where it runs | |---|---| | linux/riscv64, linux/arm (v7), linux/ppc64le, linux/s390x, linux/loong64 | under qemu-user (the `qemu-user` package; Ubuntu 26.04 no longer has `qemu-user-static`) on `ubuntu-26.04` | | linux/386 | natively on `ubuntu-26.04` (an x86-64 kernel runs 32-bit x86) | | android/arm64 | on `ubuntu-26.04-arm`, loaded by Linux's own loader: the test binary names Android's `/system/bin/linker64` but links no libraries | | freebsd/amd64, openbsd/amd64, netbsd/amd64 | in a virtual machine of each (vmactions) | s390x is big-endian, so it checks that no answer, and no CID, depends on byte order. Releases gain linux/386, linux/ppc64le, linux/s390x, linux/loong64 and openbsd/arm64. All of them build the whole daemon without cgo. netbsd/arm64 is the one target a dependency refuses. The daemon guide's table and the README say what runs where. All ten jobs pass on this PR's last run. ## How it was checked - Locally: `go test -c ./packages/runtime` succeeds for all eleven targets (the seven new here and four more), and `go build ./apps/sisyphusd` for each new release target. - This PR's CI runs each new job.
Owner

Hey @rvnminers-A-and-N — I checked the first CI run for the new matrix, and it caught two concrete runner assumptions:

  • The five Linux/QEMU jobs fail before running tests because Ubuntu 26.04 treats qemu-user-static as a virtual package with no install candidate (APT lists qemu-user-binfmt / qemu-user-binfmt-hwe as providers). The job will need to install a package available on this image and make sure the emulator executable names used by the matrix are present.
  • The Android/arm64 test binary compiles, but running it directly on the Ubuntu ARM runner fails with “cannot execute: required file not found.” So the current “same kernel ABI / static binary” assumption isn’t enough for execution there; this needs an Android runtime/emulator, or the job should limit its claim to cross-compilation until we can run it under Android.

The native x86/386 and the BSD VM jobs passed in this run. I haven’t changed your branch; wanted to share the exact failure evidence while the PR is still a draft.

Hey @rvnminers-A-and-N — I checked the first CI run for the new matrix, and it caught two concrete runner assumptions: - The five Linux/QEMU jobs fail before running tests because Ubuntu 26.04 treats `qemu-user-static` as a virtual package with no install candidate (APT lists `qemu-user-binfmt` / `qemu-user-binfmt-hwe` as providers). The job will need to install a package available on this image and make sure the emulator executable names used by the matrix are present. - The Android/arm64 test binary compiles, but running it directly on the Ubuntu ARM runner fails with “cannot execute: required file not found.” So the current “same kernel ABI / static binary” assumption isn’t enough for execution there; this needs an Android runtime/emulator, or the job should limit its claim to cross-compilation until we can run it under Android. The native x86/386 and the BSD VM jobs passed in this run. I haven’t changed your branch; wanted to share the exact failure evidence while the PR is still a draft.
Owner

Good timing, @rvnminers-A-and-N — #258 has now merged to dev, so the base is ready for the rebase you described. The first-run CI findings are in my note above; once you push the refreshed branch, I’m happy to check the rerun and help with any remaining failures.

Good timing, @rvnminers-A-and-N — #258 has now merged to `dev`, so the base is ready for the rebase you described. The first-run CI findings are in my note above; once you push the refreshed branch, I’m happy to check the rerun and help with any remaining failures.
Author
Owner

@excho0, thanks. Both are fixed in d6dc125, rebased on dev after #258: qemu-user (the plain emulators, called as qemu-riscv64 and so on) instead of the gone qemu-user-static, and the Android test binary loaded through /lib/ld-linux-aarch64.so.1, since it asks for Android's /system/bin/linker64 but has no libraries to link. Android, FreeBSD, RISC-V and 386 now pass; the rest are waiting for runners.

@excho0, thanks. Both are fixed in `d6dc125`, rebased on `dev` after #258: `qemu-user` (the plain emulators, called as `qemu-riscv64` and so on) instead of the gone `qemu-user-static`, and the Android test binary loaded through `/lib/ld-linux-aarch64.so.1`, since it asks for Android's `/system/bin/linker64` but has no libraries to link. Android, FreeBSD, RISC-V and 386 now pass; the rest are waiting for runners.
Owner

Hey @rvnminers-A-and-N — the new cross-platform workload checks look good, and the current matrix is green. I did notice one coverage gap before this is ready: workload-elsewhere compiles only ./packages/runtime test binaries, while build-release.sh now adds daemon release targets (including OpenBSD/arm64). The existing go build ./apps/sisyphusd check still runs only on the host runner, so CI would not catch a daemon-only compile break on those added targets. Could we add a lightweight cross-build of the daemon for each newly supported release target (including OpenBSD/arm64), alongside the workload checks? The local cross-builds in the PR description are good evidence for this commit, but a CI check would keep the release list covered going forward. Thanks!

Hey @rvnminers-A-and-N — the new cross-platform workload checks look good, and the current matrix is green. I did notice one coverage gap before this is ready: `workload-elsewhere` compiles only `./packages/runtime` test binaries, while `build-release.sh` now adds daemon release targets (including OpenBSD/arm64). The existing `go build ./apps/sisyphusd` check still runs only on the host runner, so CI would not catch a daemon-only compile break on those added targets. Could we add a lightweight cross-build of the daemon for each newly supported release target (including OpenBSD/arm64), alongside the workload checks? The local cross-builds in the PR description are good evidence for this commit, but a CI check would keep the release list covered going forward. Thanks!
Sign in to join this conversation.
No Reviewers
No labels infra testing
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Sisyphus/Sisyphus#261