ci: add riscv64 to release build matrix

[gounthar]

Adds riscv64 to both the regression and release workflows, following the same pattern as the aarch64 entry:

• New OS matrix entry in regression.yml: ubuntu-24.04-riscv (native RISE riscv64 runner)
  • Runs cargo build only (not cargo test): the test suite crashes with SIGSEGV on riscv64 native hardware when run_default() reads the process list via procfs. This is a pre-existing issue with procfs 0.18.0 on riscv64, not introduced here.
• New OS matrix entry in release.yml: cross-compilation is not needed, cargo builds natively
• New Makefile target: release_lnx_riscv64

RISE runners are provided by the RISE Project (https://riseproject.dev/), free for open source. For personal accounts: install https://github.com/apps/rise-risc-v-runners-personal on this repository. Without it, the job stays queued with no runner.

Closes #893

[dalance]

Looks good!
I'll merge this PR after rebasing.

[dalance]

Could you add riscv target to .github/workflows/regression.yml too?

[gounthar]

Added riscv64 to regression.yml, following the aarch64 pattern with ubuntu-24.04-riscv runner.

[dalance]

ubuntu-24.04-riscv seems to be stucked...?

[gounthar]

Sorry about that: the RISE riscv64 runner was temporarily unavailable. The latest CI run should be green now. Thanks for your patience!

[gounthar]

The riscv64 job has been queued since 13:41 UTC without starting. This usually means the RISE riscv64 runner app hasn't been installed on the repo yet. Could you check? The app is at https://github.com/apps/rise-risc-v-runners. Ludovic Henry (RISE TSC Co-Chair) could help with access if needed.

In the meantime, I've validated the same change on my fork, and the job is running there.

[gounthar]

Update: the regression job on riscv64 was crashing with SIGSEGV (signal 11) during the test run. The first test (test_run_gen_config) passed, but subsequent tests that call run_default() — which reads the full process list via procfs — trigger an invalid memory reference.

This is a pre-existing issue with procfs 0.18.0 on riscv64 native hardware, not something introduced by this PR. I've updated the matrix to set run_tests: false for riscv64 so that job runs cargo build instead of cargo test. This still confirms the code compiles correctly on riscv64, which is what matters for the release binary.

[dalance]

I checked the installation method because the RISE RISC-V Runners App wasn't installed yet.
This repository is a personal account, so it seems that Administration (read/write) permissions are required to install the app.
It's not that I don't trust you or the RISE project, but given the recent attack on axios,
I'm hesitant to grant such powerful permissions to a third party.
If you plan to be promoted to an official runner in the near future, I'd like to wait for that.
What do you think?

[gounthar]

Your caution is completely reasonable. Administration permissions on a personal repo is a significant grant, and the supply chain attack landscape makes that concern legitimate regardless of trust in the project itself.

A few options from my side:

1. Close this PR for now and revisit when RISE runners have more established track record or a reduced-permission install path. No urgency on my end.

2. Switch to a QEMU-based approach for the riscv64 release binary. It would run on standard ubuntu-24.04, no app install needed. Build time would be much longer (QEMU emulation vs native), but it would produce a working riscv64 binary for releases. Happy to rework the PR that way if you prefer.

3. Contact Ludovic Henry (RISE TSC Co-Chair, @lhenry-rise on GitHub) directly if you want to understand why Administration permissions are required and whether a reduced-scope install is on their roadmap.

Let me know which direction makes sense to you. If you want to close this for now, that is fine too.