kubevirt
Three functional tests helper images do not build as multi-arch for ARM or s390x
What happened:
Running make all that builds the CDI operator, unit tests and most containerized functional tests does multi-arch builds correctly for ARM and s390x, but 3 functional tests -- bad-webserver, proxy and sample-populator -- still build as x86 containers.
What you expected to happen:
Running make all with BUILD_ARCH set with ARM or s390x targets aarch64 crossbuild-aarch64 s390x crossbuild-s390x should build all the relevant functional tests as the intended target architecture.
How to reproduce it (as minimally and precisely as possible):
on s390 build host:
BUILD_ARCH=s390x make push
on x86 build host:
BUILD_ARCH=crossbuild-s390x make push
both produce the following suite of containers:
kubevirt/cdi-apiserver "Architecture": "s390x",
kubevirt/cdi-cloner "Architecture": "s390x",
kubevirt/cdi-controller "Architecture": "s390x",
kubevirt/cdi-importer "Architecture": "s390x",
kubevirt/cdi-operator "Architecture": "s390x",
kubevirt/cdi-uploadproxy "Architecture": "s390x",
kubevirt/cdi-uploadserver "Architecture": "s390x",
kubevirt/cdi-func-test-file-host-http "Architecture": "s390x",
kubevirt/cdi-func-test-file-host-init "Architecture": "s390x",
kubevirt/cdi-func-test-registry "Architecture": "s390x",
kubevirt/cdi-func-test-registry-init "Architecture": "s390x",
kubevirt/cdi-func-test-registry-populate "Architecture": "s390x",
kubevirt/cdi-func-test-bad-webserver "Architecture": "amd64",
kubevirt/cdi-func-test-sample-populator "Architecture": "amd64",
kubevirt/cdi-func-test-proxy "Architecture": "amd64",
I present only the results for s390x and crossbuild-s390x here, but I understand from @awels that this is a problem for ARM as well.
Additional context:
The bazel rules for building container images with golang with the methods in these 3 tests is archived
https://github.com/bazelbuild/rules_docker/blob/master/go/image.bzl
whereas the methodology used to build the other functional test containers are built differently, and at least come out with the right image format; the consensus with @akalenyu and @awels is that we should convert these 3 functional test containers to use the methodology used to build the other 5.
Another thing to take into consideration is that make build-functest builds the specific go tests that use these helper images.
Environment:
- CDI version (use
kubectl get deployments cdi-deployment -o yaml): main - Kubernetes version (use
kubectl version): N/A - DV specification: N/A
- Cloud provider or hardware configuration: N/A
- OS (e.g. from /etc/os-release): N/A
- Kernel (e.g.
uname -a): N/A - Install tools: N/A
- Others: N/A
These three helper containers build in qemu emulation for the nightlies do build as s390x image format, such that:
- e2e testing can proceed with helper containers built in nightlies
- we can look to the build environment & configuration of the automated periodic nightlies crossbuilds to solve the image format issues in the manual crossbuild and native builds
- @awels you might find this interesting, wonder if the same is true for
aarch64
These three helper containers build in qemu emulation for the nightlies do build as s390x image format, such that:
e2e testing can proceed with helper containers built in nightlies