The security concern raised here is worth thinking through. Third-party CI runners see your workflow environment — that's the actual trust boundary.
For public repos (the primary target here), the bigger practical concern is usually the opposite: your workflows fire webhooks to external systems and you have no visibility into what those systems actually received. This is especially true when integrating notification or deployment hooks that run after a successful test suite. The architecture step (source → RISC-V runner → build artifact → deployment hook) adds another hop where payloads can be malformed or swallowed silently.
The Linux Foundation backing does address the trust question well. RISE's membership list reads like a who's who of RISC-V commercial stakeholders — the incentive structure is to build trust in the ecosystem, not undermine it.
My experience with RISC-V so far is that the chips are not much faster than QEMU emulation. In other words, it's very slow.
Sadly still on quite old hardware, with no RVV. Hopefully scaleway will have some newer servers in the future and this can be simply updated to the new devices.
Very good move. Hopefully GitHub won't ruin this with their CI charging changes.
GitHub only :(
Perfect for snooping on other people’s projects. No one in their right mind would touch this. It’s cheaper to buy the board yourself.
I’m a fan of this, although I’m concerned about the security/trust model: using a third-party CI orchestrator on top of GHA means trusting them with all of your secrets, potentially sensitive logs, etc. Those concerns are somewhat lessened in the context of public repos, but even public repos contain nontrivial workflows that use configured secrets.