CI: support ci job on riscv64 hardware

[yuzibo]

As we have discussed [this](#t-infra > We're eager to provide the community with RISC-V CI infrastr @ 💬) on zulipchat channel, let's focus on some details on how to push this.

[yuzibo]

The main steps for the job that I refer to the main.yml.

They are:

• Update/Download Code
• Print runner information
• Configure Rustup(install rustup)
• Download/Cache compiler-rt
• Download musl source
• Verify API list
• Run locally test

Because we have run the Job in Docker, so I run ./ci/run.sh instead of ./ci/run-docker.sh here.

Is it enough for one CI job on riscv64? Maybe it is good to add benchmarks test here, but I am not sure about this.

[tgross35]

Those look like the important steps! Really ./ci/run.sh is the important bit, how you get there shouldn't matter too much.

The icount benchmarks would be nice eventually since it lets us make sure we don't regress performance on risc-v. But they're probably a bit trickier to set up so that can come later.

Happy to accept a PR here when you're ready.

[tgross35]

The icount benchmarks would be nice eventually since it lets us make sure we don't regress performance on risc-v. But they're probably a bit trickier to set up so that can come later.

More specifically, they should be pretty easy to actually run since it's just getting the right dependencies then running the script. But doing anything with the results is probably trickier: currently we upload the results as a CI artifact, then download the artifact from the latest run on main to compare against and fail the job if there are regressions. That part isn't strictly required, though.

[tgross35]

Another note: if you can install nextest on the system like we do in CI, that can speed up test runs quite a bit (though they're not much slower than our current slowest jobs). run.sh detects it automatically.

[yuzibo]

Many thanks for kindly guiding. I have proposed one commit to support the CI job on riscv64 hardware.

Highlight:

• Self hosted runner fully, no longer interacting with Jenkins;
• Multiple nodes for the CI job.

This is my experimental.

[yuzibo]

My only concern is that it requires self-hosted runner token to register the runner. Furthermore, this token has a fixed validity period, during which multiple runners can be registered using the same token.

Each repo can use multiple tokens to register multiple runner.

[yuzibo]

More specifically, they should be pretty easy to actually run since it's just getting the right dependencies then running the script. But doing anything with the results is probably trickier: currently we upload the results as a CI artifact, then download the artifact from the latest run on main to compare against and fail the job if there are regressions. That part isn't strictly required, though.

I postponed to enable this at this moment due to time limited then I will have a look at this again.

[tgross35]

Thank you for getting this started!

My only concern is that it requires self-hosted runner token to register the runner. Furthermore, this token has a fixed validity period, during which multiple runners can be registered using the same token.

I'm not sure exactly what is needed here, but you should bring it up on the T-infra zulip