ci: the workloads checked on every other system a release is built for #261
No Reviewers
Labels
Clear labels
accessibility
all-platforms
area:agents
area:ai
area:chain
area:ci
area:client
area:daemon
area:p2p
area:project
area:protocol
area:runtime
area:storage
bug
chore
community
dependencies
discussion
discussion/Announcements
discussion/General
discussion/Ideas
discussion/Q&A
discussion/Show and tell
discussion/answered
documentation
duplicate
enhancement
good first issue
help wanted
i18n
infra
invalid
needs:decision
needs:hardware
paired
question
research
security
status:in-review
test
testing
tracking
wontfix
Barrier affecting people with disabilities
Run every platform's packaging and checks on this pull request, not only the three main ones
MCP server, skill, and thinking on the pool
Planner and model providers
Blockchain, SISY, verification
Continuous integration and build workflows
Desktop and web clients
sisyphusd coordinator, worker, scheduler
libp2p hosts, relays, discovery, connections between nodes
Project planning, roadmap, and governance
Protobuf schemas and RPC contracts
Workload execution and environments
Content-addressed storage, IPFS, Kubo, Cluster, S3, names, pinning
Something isn't working
Repository health, templates, Discussions, contributor experience
Updates to actions, Go modules or npm packages
Migrated from GitHub Discussions
GitHub Discussions category: Announcements
GitHub Discussions category: General
GitHub Discussions category: Ideas
GitHub Discussions category: Q&A
GitHub Discussions category: Show and tell
Q&A discussion with an accepted answer
Improvements or additions to documentation
This issue or pull request already exists
New feature or request
Good for newcomers
Extra attention is needed
Translations and right-to-left layouts
Build, CI, releases
This doesn't seem right
Waits on a decision from both owners
Waits on a machine we do not have yet
Built together by both maintainers, with co-authored commits
Further information is requested
Needs investigation or a design decision
Sealing, keys, access control, tokens, the security model
Built and in an open pull request; closes when it merges
Tests, test harnesses and the rehearsal
Roadmap and meta issues
This will not be worked on
type
Feature
A request, idea, or new functionality (GitHub issue type)
type
Task
A specific piece of work (GitHub issue type)
Milestone
No items
No Milestone
First release
Projects
Clear projects
No projects
Sisyphus roadmap
Done
No Assignees
rvnminers-A-and-N
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Sisyphus/Sisyphus#261
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What and why
Releases build
sisyphusdfor 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:qemu-userpackage; Ubuntu 26.04 no longer hasqemu-user-static) onubuntu-26.04ubuntu-26.04(an x86-64 kernel runs 32-bit x86)ubuntu-26.04-arm, loaded by Linux's own loader: the test binary names Android's/system/bin/linker64but links no librariess390x 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
go test -c ./packages/runtimesucceeds for all eleven targets (the seven new here and four more), andgo build ./apps/sisyphusdfor each new release target.Hey @rvnminers-A-and-N — I checked the first CI run for the new matrix, and it caught two concrete runner assumptions:
qemu-user-staticas a virtual package with no install candidate (APT listsqemu-user-binfmt/qemu-user-binfmt-hweas 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 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.
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.@excho0, thanks. Both are fixed in
d6dc125, rebased ondevafter #258:qemu-user(the plain emulators, called asqemu-riscv64and so on) instead of the goneqemu-user-static, and the Android test binary loaded through/lib/ld-linux-aarch64.so.1, since it asks for Android's/system/bin/linker64but has no libraries to link. Android, FreeBSD, RISC-V and 386 now pass; the rest are waiting for runners.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-elsewherecompiles only./packages/runtimetest binaries, whilebuild-release.shnow adds daemon release targets (including OpenBSD/arm64). The existinggo build ./apps/sisyphusdcheck 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!