Thanks for opening a pull request!

If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose

Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project.

Then could you also rename the pull request title in the following format?

GH-${GITHUB_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

or

MINOR: [${COMPONENT}] ${SUMMARY}

See also:

• Other pull requests
• Contribution Guidelines - Contributing Overview

⚠️ GitHub issue #49555 has been automatically assigned in GitHub to PR creator.

⚠️ GitHub issue #49555 has no components, please add labels for components.

Hi @gounthar , the big question here is what happens for ongoing maintenance. I think none of the currently active Arrow maintainers has a RISC-V box at home, and debugging on CI can be painful. But I might be overstating the risks.

also cc @raulcd

@pitrou That's a fair concern. A few things that mitigate it:

1. RISE runners are native hardware: not QEMU emulation. Debugging and iteration is much faster (we validated the full Arrow C++ + pyarrow build on native hardware in ~1.5h total).

2. I maintain two BananaPi F3 boards running 24/7 as riscv64 build/test machines. Happy to help debug any riscv64-specific issues that come up.

3. The riscv64 job would be additive: if it breaks, it doesn't affect existing x86_64/aarch64 builds. Same as how aarch64 was initially added.

4. Arrow C++ is already riscv64-compatible (PR ARROW-17440: [C++] Support RISC-V architecture #13902, 2022). The risk of riscv64-specific breakage in the wheel pipeline is low since the code itself work; it's mainly CI plumbing.

5. RISE is committed to maintaining riscv64 CI for key projects. Ludovic Henry (RISE TSC Co-Chair) is actively providing runners and support; this isn't a fire-and-forget contribution.

I'm also happy to be a point of contact for riscv64 issues in Arrow. I've been doing this across several Python projects this week and can respond quickly.

@raulcd Great question. The RISE runners app requires these permissions:

• Actions: Read and write (to register/deregister runners)
• Metadata: Read-only

It's a GitHub App that provides self-hosted runners, similar to how some projects use BuildJet or Actuated for ARM runners.

As for Apache org setup: I'm not aware of other Apache projects using RISE runners yet, you'd likely be the first. I can check with Ludovic Henry (@luhenry, RISE TSC Co-Chair) about the process for Apache org installation. He's been setting up runners for numpy, pytorch, llama.cpp, and pyca this week.

Alternatively, we could initially run the riscv64 job on a separate fork (like we did with riseproject-dev/numpy) and upstream once the runner setup is confirmed. That way the PR can be reviewed independently of the infra question.

I'll ping Ludovic about Apache org support and report back.

@raulcd @pitrou: Ludovic Henry (@luhenry, RISE TSC Co-Chair) should respond directly on this PR about the Apache org runner setup. He hasn't set up RISE runners on Apache projects before but is very interested in making it happen.

To be set-up as part of the Apache organization. A couple of questions about that. Do we know what are the required permissions? Has this been set-up on other Apache projects or are we the first ones? Asking as might require some ASF INFRA research.

The requested permissions are:

• At repository level:
  • Actions: read-only
  • Metadata: read-only (mandatory as well)
• At organization level:
  • Self-hosted runners: read and write; necessary to add the self-hosted runners and runner group

We are not going to require any more credentials as we only want to be able to dynamically register self-hosted runners, and that's it. You can find all the code of the app at https://github.com/riseproject-dev/riscv-runner-app, and a more descriptive website at https://riseproject-dev.github.io/riscv-runner/

RISE is committed to maintaining riscv64 CI for key projects

RISE is part of Linux Foundation EU, and is committed to this service. We see it as a critical piece to enable RISC-V Software more broadly, which is our entire raison d'être. We are also working with PyTorch, Llama.cpp, and many other projects to enable CI on RISC-V.

Also happy to drastically increase the number of runners available for the Apache organization, given the overall importance of everything that you're doing!

For any direct board access, we are also working on a service of remote, on-demand machines accessible via SSH. Exactly for this kind of purpose where someone needs to debug a sticky issue and for which it's a great productivity loss to go through CI.

Let me know if you have any other questions.

Thanks for the answers @gounthar . Can we perhaps start by having a regular C++ CI job on RISC-V? The Python wheel CI builds do not run the C++ test suite.

@pitrou That makes a lot of sense, start with the foundation. I'll rework this PR to add a C++ CI job on riscv64 instead of jumping straight to wheel builds.

I've already verified that Arrow C++ builds and passes import pyarrow on native riscv64. I'll look at the existing C++ CI jobs (ci/docker/ubuntu-*-cpp.dockerfile and the corresponding workflows) and add a riscv64 variant.

Would you prefer:

1. A Docker-based build (like the existing CI), or
2. A native build on the RISE runner directly (simpler, but less isolated)?

Definitely a Docker-based job! You can take a look here for inspiration:

Note that this uses archery docker, which relies on compose.yaml. See https://arrow.apache.org/docs/developers/continuous_integration/docker.html, and feel free to ask any questions!

@pitrou Thanks for the pointer! I'll study the archery docker approach and the compose.yaml service definitions for the C++ CI job. 🙏

I'll rework this PR to add a ubuntu-cpp-riscv64 service in compose.yaml and a corresponding CI workflow, following the pattern from cpp.yml#L74. Will likely need to figure out the Docker image base (manylinux_2_39_riscv64 or a Ubuntu-based image for riscv64). 🤔

Will report back once I have a working prototype. 🤞

Update on the C++ CI work: got the Docker-based build running on a RISE riscv64 runner (ubuntu-24.04-riscv). The build itself completes (2257 C++ files, ~4h), but the test suite crashes systematically - all 59 test binaries fail in ~2 seconds each, which looks like a SIGILL or similar architecture-level issue.

The Docker image build had a couple of hurdles:

• install_minio.sh crashes on unknown arches due to set -u + unbound array key (one-line fix: ${archs[$arch]:-})
• Docker 26.1.5 on the runner has a BuildKit bug; works with DOCKER_BUILDKIT=0

I'm going to run the tests directly on native hardware (BananaPi F3) to get the actual error output - the CI redirects test logs into files so the crash reason isn't visible. Will report back with the findings.

Fork CI run: https://github.com/gounthar/arrow/actions/runs/23411999463

Correction on the above: the CI run did use the Docker-based approach (archery docker run ubuntu-cpp) as you suggested. The build and tests ran inside the Docker container on the RISE runner. The test crashes are from inside the container, not a bare-metal build.

I'm also going to reproduce the Docker-based build on my BananaPi F3 to get the test crash output (the CI redirects logs to files). Will use archery docker run ubuntu-cpp there as well to match the CI environment.

Update on the C++ CI work: got the Docker-based build running on a RISE riscv64 runner (ubuntu-24.04-riscv). The build itself completes (2257 C++ files, ~4h)

4 hours to complete a native build sounds like... a lot.

install_minio.sh crashes on unknown arches due to set -u + unbound array key (one-line fix: ${archs[$arch]:-})

Please note you can disable individual components using environment variables, you can get an idea by the cmake invocation here.

I'm going to run the tests directly on native hardware (BananaPi F3) to get the actual error output - the CI redirects test logs into files so the crash reason isn't visible.

Ideally, our test harness is able to display crash tracebacks using gdb, though the logic behind that is fragile and doesn't always work reliably.
See these instructions in compose.yaml.

@pitrou Good points.

The 4h includes the Docker image build (~20 min for apt packages) + C++ compilation. The RISE runner is a Scaleway EM-RV1 which isn't the fastest riscv64 hardware. On my BananaPi F3 (8 cores, SpacemiT K1), the C++ build alone takes about 1h13m. Disabling some components would help; I'll trim the feature set for the CI job.

Thanks for the pointer on disabling components via env vars and on the gdb traceback support in compose.yaml. I'm running the Docker-based build on the F3 now with archery; will check if gdb picks up the crash reason.

For the minio fix, I can submit a separate small PR for install_minio.sh if that's useful, or fold it into this one.