Multi-Architecture ARM Image is still x86_64 based #2241
Description
Component(s)
router, controlplane, studio, composition, otelcollector, graphqlmetrics
Component version
n/a
wgc version
n/a
controlplane version
sha-f883504
router version
n/a
What happened?
Description
The docker images are using the syntax --platform=${BUILDPLATFORM} which specifies that the base image should be the same architecture as the host platform. Docker's default uses the TARGETPLATFORM if you don't specify anything, which is what should be done. Currently, the multi-architecture manifest that is shipped specifies that there is an arm image available, but since the actions are built using ubuntu-latest, and the base images are requesting the build platform, the final arm image is actually an amd64 runtime.
Steps to Reproduce
- Pull the arm architecture image.
- Run
uname -mproduces
Expected Result
aarch64
Actual Result
x86_64
Environment information
Environment
OS: macOS M1 Sonoma 14.7.8, AWS Graviton EC2
Package Manager: pnpm
Compiler(if manually compiled): Docker?
Router configuration
n/aRouter execution config
n/aLog output
docker run -it ghcr.io/wundergraph/cosmo/controlplane:sha-f883504@sha256:4453335c10c902a43173b45eaf1add92dafcf8aa885a327cbf8a816b26638be5 /bin/ash
/app # uname -m
x86_64Additional context
I'll be submitting a PR removing the build platform argument in the docker files. I've tested this locally on my macOS M1, and I've run a version of the controlplane image on our EKS Graviton instances with the change. I was able to pull down the amd64 platform image on my macOS and run it verifying that it's still an amd runtime. However, I don't actually have any true amd64 runtimes, so all of my verifications have relied on the QEMU emulation so far. Someone probably needs to test that the final built amd64 image is valid in a true amd64 host.