ci: add riscv64 manylinux wheel builds

[gounthar]

Add native riscv64 wheel builds using RISE RISC-V runners (ubuntu-24.04-riscv) — no QEMU emulation.

Changes

• New manylinux-riscv64 job in wheel-builder.yml
• Uses native RISE riscv64 runners (as discussed — no QEMU)
• Installs Rust via rustup, Python from /opt/python-3.12
• Cargo registry cached across runs
• Same smoke test as existing jobs

Evidence

• Build time: ~5.5 minutes on native hardware
• Validated on RISE fork: ci: add native riscv64 wheel builds using RISE runners riseproject-dev/bcrypt#1
• Native build on BananaPi F3 (SpacemiT K1, rv64gc): SUCCESS
• RISE runners provided by Ludovic Henry / RISE project (free for open source)

Context

Updated per @reaperhulk's feedback — switched from QEMU to native runners.

Related: riscv64 Docker images for pyca infra: pyca/infra#748

[reaperhulk]

Thanks for the contribution but we won’t ship wheels for architectures we don’t test. For CI we require native (and ephemeral) runners with sufficient performance as a general rule to keep our CI pleasant to use, so qemu isn’t an option there unfortunately.

[gounthar]

@reaperhulk Understood, makes total sense. Native riscv64 runners are becoming available through RISE, which provides free ephemeral self-hosted runners on real hardware. I'll revisit this once those are ready for pyca. Thanks for considering it.

[gounthar]

@reaperhulk Updated. Switched from QEMU to native riscv64 runners provided by RISE. Build time is ~5.5 minutes on real hardware. Validated on a fork: riseproject-dev#1

Also opened pyca/infra#748 for the riscv64 Docker images needed for the full pyca build pipeline.

[gounthar]

@luhenry Thank you for enabling the RISE riscv64 runners that made this possible. Would it be possible to add native runners for the pyca organization as well? That would unblock riscv64 wheels for cryptography, bcrypt, and pynacl, three of the most downloaded packages on PyPI.

[luhenry]

@luhenry Thank you for enabling the RISE riscv64 runners that made this possible. Would it be possible to add native runners for the pyca organization as well? That would unblock riscv64 wheels for cryptography, bcrypt, and pynacl, three of the most downloaded packages on PyPI.

I’ll add them tomorrow. Now that we have access to more runners I’ll make sure to lift the restriction on registered organizations

[luhenry]

@reaperhulk 👋 hello, just a quick follow up on that. Please let me know if you are interested in adding the RISE RISC-V Runners for native riscv64 runners, or if you have any other questions. They are ready for prime-time as they are used in some projects already (llama.cpp, kubetail, numpy (wip), and others). Happy to help however I can. Thank you!

[gounthar]

Pushed a fix for the RISE runner image rebuild on 2026-04-22.

The job was hardcoding /opt/python-3.12/bin/python3.12 to create the venv. That path is gone now. Switched to actions/setup-python@v5 (works natively on riscv64) and python3 -m venv .venv from there.

The PR description's "Python from /opt/python-3.12" line is stale now too.

Validation run on fork (commit 3b8e9e4):
https://github.com/gounthar/bcrypt/actions/runs/25305195033

[gounthar]

@reaperhulk Following up after a month. Fork CI is fully green on all riscv64 jobs after I fixed a setup-python path issue on May 4: https://github.com/gounthar/bcrypt/actions/runs/25305195033

The RISE riscv64 runners are self-service, btw; pyca org installs the GitHub App directly at https://github.com/apps/rise-risc-v-runners, no coordination needed on my end. Worth a look if you have bandwidth.

[luhenry]

@gounthar what's the motivation to have the separate manylinux_riscv64 job rather than adding an entry in manylinux's matrix?

[gounthar]

The manylinux job runs inside pyca's custom Docker containers (ghcr.io/pyca/cryptography-manylinux_2_28:x86_64 and friends), which preinstall Python at /opt/python/cpXX-cpXX/ and have a staticnode workaround baked in for Actions support. No riscv64 variant of those images exists yet. That's pyca/infra#748.

Without the container, the /opt/python step just breaks, and I wasn't sure how staticnodehost volume mounts behave on RISE runners either; you'd know better than I do on that one.

So the separate job is a workaround: "bare-metal" on the RISE runner, Python from actions/setup-python, auditwheel and Rust installed fresh each time.

Once riscv64 containers land in ghcr.io/pyca, folding into the matrix is the obvious move. I could restructure it now to use a matrix entry with ubuntu-24.04-riscv while skipping the container block, but it'd need extra excludes for Python versions that don't apply on riscv64 yet. Not sure that churn is worth it vs. waiting for infra#748, but happy to do it if you think it's cleaner.