Closed bcfriesen closed 1 week ago
Partially addresses https://github.com/OpenCHAMI/bss/issues/24, but only for SMD.
This PR is still marked as a WIP, but we have some relevant input given our previous forays into multiarch builds.
We need to be able to build both binaries and containers with the pipeline using github actions and goreleaser. Check out https://goreleaser.com/cookbooks/multi-platform-docker-images/ for guidance.
Where we're using CGO instead of pure GO, there are areas where building the binary may not work correctly because it links to existing C libraries that are built for only one architecture. Be sure to test that the binaries function before adding them to containers.
The wolfi base image we rely on should be fine as a multi-arch base, but we had some errors a while ago that made me wonder if we were specifying it correctly.
Thanks! I'll work on all 3 of those.
Working on item 1, I ran into some problems testing goreleaser
on my workstation - some issue with Docker contexts that I don't yet understand but which seems to be documented in https://github.com/goreleaser/goreleaser/issues/4392.
Working on item 1, I ran into some problems testing
goreleaser
on my workstation - some issue with Docker contexts that I don't yet understand but which seems to be documented in goreleaser/goreleaser#4392.
That was fixed by updating goreleaser
. On to the next problem:
> [stage-1 3/8] RUN set -ex && apk -U upgrade && apk add --no-cache curl:
0.104 + apk -U upgrade
0.129 fetch https://packages.wolfi.dev/os/x86_64/APKINDEX.tar.gz
0.398 WARNING: opening from cache https://packages.wolfi.dev/os: No such file or directory
0.398 ERROR: Not continuing due to stale/unavailable repositories.Use --force-missing-repositories to continue.
closed because we found another way to address it in #40
With this change, the target architecture for the container image can be selected with environment variables in the build environment, rather than being hard-coded into the Makefile. If the
GOOS
andGOARCH
environment variables are unspecified, the container image is built to targetlinux/amd64
, which is the same behavior as before.This has been tested with
linux/arm64
, which takes around 15 minutes to build the SMD image on a modern x86-based server.One thing I don't like about this change is that the Dockerfile now downloads a
golang
container image from the internet, which seems to conflict with software provenance goals for the project. I am not sure what is the best approach to address that.