Build riscv64 image

[ffgan]

What this PR does / why we need it:

I'm currently working on adding riscv64 support for kubevirt, as detailed in kubevirt/containerized-data-importer#3948. While adding support for CDI, I discovered that this repository needs riscv64 support as well, so I've opened this PR to add riscv64 support.

By checking gcr.io/distroless/base:latest and alpine:latest , we can see the following table:

arch	distroless/base	alpine
amd64	Y	Y
arm64/v8	Y	Y
arm/v7	Y	Y
s390x	Y	Y
ppc64le	Y	Y
riscv64	N	Y
386	N	Y
arm/v6	N	Y

Clearly, Alpine has excellent multi-architecture support. Should we consider switching from distroless/base to Alpine to gain riscv64 support? I believe there shouldn't be any compatibility issues between the two, but I haven't yet found a good approach for testing this image in CI. If I find one, I'll submit the relevant PR promptly.

For now, I've run the CI in my own fork, and the results show everything is working smoothly. Details are as follows:

1. prom-metrics-linter
2. Generate a build and push to 'ghpages' branch
3. Sanity Checks

If you have any questions about the above content, please feel free to contact me directly. I'm happy to answer any related questions.

---

Release note:

Build riscv64 image

---

Otehr Info
Co-authored by: nijincheng@iscas.ac.cn;

[sradco]

@avlitman @nunnatsa can you please have a look?

[nunnatsa]

Thanks for the PR, @ffgan .

First: is the effort to add riscv64 support is managed by the community? do you have an approved VEP for it?

Also, this image is a build tool. Are you going to run it on a riscv64 machine? or build from another machine for riscv64?

[ffgan]

Hi @nunnatsa ,Thank you for your reply.

Regarding VEP, it is still in a relatively early stage at the moment, so we don't have that yet.

Regarding whether to run on riscv64 or on other machines, I may not quite understand what you're referring to.

[ffgan]

Regarding this PR, I submitted it because when I was running CDI on riscv64, I discovered that support for this container was missing, so I raised this PR.

[nunnatsa]

Regarding VEP, it is still in a relatively early stage at the moment, so we don't have that yet.

You should start from VEP... this should be your first step.

[ffgan]

You should start from VEP... this should be your first step.

Okay, then I'll prepare for it in the near future and try to apply for VEP as early as possible.

[ffgan]

Hi @nunnatsa .

I've already started a VEP, welcome to check it out.

[kubevirt-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[kubevirt-bot]

There has been no activity on this PR for 59 days and it has been stale for 14 days.
To protect limited CI resources, it has been automatically labelled 'rotten' and will be closed in 7 days.

What you can do:

• If the PR is waiting on you to respond to a question or feedback and/or update the PR, please do so.
• You can mark the PR as fresh and remove the label with the following command: /remove-lifecycle rotten
• If this PR is safe to close now, please help the project by closing it with: /close
• If you need attention on this PR from a reviewer, you can raise it on the agenda of the relevant SIG meeting or KubeVirt Community meeting, or ping the kubevirt-dev slack channel.

/lifecycle rotten