build: Add support for RISC-V #12067
Conversation
|
I don't know much about RISC-V so I'll defer the review to others who are more experienced |
Signed-off-by: Antony Chazapis <chazapis@ics.forth.gr>
There was a problem hiding this comment.
IMO, I don't think we should add support for new architectures that do not have significant user requests. In this case, this seems pre-emptive to user requests (correct me if I'm wrong).
Argo CD supports a few different archs, but that doesn't currently include RISC-V. Those different archs do also slow down the build considerably for some rare use-cases.
Adding support for a new arch means a new maintenance burden for that arch. If there are no user requests for that, that maintenance burden seems not worthwhile. Given the unstable status of several upstream projects as you mentioned, that sounds even more maintenance heavy as a result
|
|
||
| RUN apk update && apk add --no-cache \ | ||
| RUN apk update && \ | ||
| (command -v go >/dev/null 2>&1 || apk add --no-cache go) && \ |
There was a problem hiding this comment.
we should add versions if we want this to match the regular alpine images.
this also feels very hacky to have different base images, but it sounds like there's no pre-built Alpine image with Go and Node for RISC-V?
| (command -v node >/dev/null 2>&1 || apk add --no-cache nodejs-current) && \ | ||
| (command -v yarn >/dev/null 2>&1 || apk add --no-cache yarn) && \ |
There was a problem hiding this comment.
same as above re: versioning
@agilgur5, I agree. However, I want to stress out that even though the RISC-V community is still small, it is constantly growing. You may not have user requests now, but RISC-V users currently just run what is available (or recompile). If Argo (and Kubernetes/K3s) were already available, I am sure people would find good use for them. A whole range of RISC-V hardware has been announced. We envision these devices to join a Kubernetes control plane and run partial workflows via Argo. Also, at this point, I think it would be perfectly acceptable to publish a build marked as experimental/untested. In any case, let me know if there is any way I can help. |
|
As an example of previous work in the industry, https://github.com/nodejs/unofficial-builds/ creates experimental builds for less common architectures like RISC-V. We could potentially have something similar in |
This PR adds RISC-V support, by generating a CLI binary for RISC-V and container images.
Motivation
The work is part of an ongoing effort to run K3s on RISC-V. The main functionality is there, so we are now moving to higher-level services and Argo Workflows is first on the list. We expect Argo Workflows to enable us to seamlessly run workflows in a hybrid hardware environment with amd64, arm64, and riscv64 hosts.
Modifications
There are no code changes in this PR, just small additions and modifications in the
Makefileand release scripts.A binary for
riscv64is created by adding the architecture to theMakefile.The container image generation is a bit trickier, as the base images used do not currently support RISC-V. Alpine supports RISC-V in the "edge" branch and distroless has deferred releasing RISC-V images until the Debian unstable branch is moved into stable (estimated in 2025). For this reason, I turned the base image names into arguments in the
Dockerfileand use different ones for RISC-V inrelease.yaml.Verification
I built container images by running the script in
release.yamlby hand. They can be found at my organization's Docker Hub account. I then modifiedinstall.yamlto use these container images and tested Argo Workflows in a QEMU setup with a RISC-V build of K3s. The installation manifest, as well as test workflow can be found here.