If the Dockerfile needs to run some command, that step fails unless
QEMU is set up properly first:
failed to solve: rpc error: code = Unknown desc = failed to load
LLB: runtime execution on platform linux/ppc64le not supported
Most repos inherit the default BUILD_PLATFORMS, which includes
Windows, but don't have the necessary Dockerfile.Windows yet. To
simplify the rollout of multiarch image builds, Windows binary
building continues to be tested (i.e. BUILD_PLATFORMS remains
unchanged), but push-multiarch skips Windows if the Dockerfile.Windows
is missing.
"make push-multiarch" matched both push-multiarch and push-%. This
seems to be none-deterministic and in at least one
repo (external-provisioner), make picked the wildcard rule which then
failed because there is no "multiarch" command.
This ambiguity gets resolved by instantiating the wildcard rules only
for existing commands. The advantage also is that "make
push-no-such-command" will fail with an obvious "No rule to make
target 'push-no-such-command'" instead of attempting to build the
command.
The approach taken here extends the existing support for
cross-compiling binaries on the build host and specifying the Go
compiler: Go is installed if needed (as in Prow testing), binaries are
build on the host, then one image is created for each platform, and
finally those are combined into a single multi-architecture image.
Developers should not be forced to build for all platforms by
default. We also don't want to copy-and-paste the go invocation for
each new platform.
To address both, the target platform(s) are now configurable via
BUILD_PLATFORMS and additional platforms are only enabled in the Prow
CI.
For now this serves as a test that the source actually compiles for
multiple platforms. Building images for different target platforms is a
different problem.
The final 1.3.0 release of the hostpath driver really uses the 1.3.0
driver image in its deployment, in contrast to the previous -rc
candidates which still used 1.2.0.
This relies on a slightly different deployment script: a "deploy.sh"
must exist which knows that it has to dump a test driver configurion
into the file pointed to with CSI_PROW_TEST_DRIVER, if that env
variable is set.
That way, we no longer need to know what capabilities the installed
driver has.
This requires adding one more parallel e2e test run with
a special focus flag because snapshot tests are still guarded
with a "[Feature:VolumeSnapshotDataSource]" tag. The setting that
skips all tests with "[Feature:.*]" has to be removed because it
overrides the focus.
We don't have serial snapshot tests yet. This needs to be modified
again if we add any in the future.
