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.
Some operations are sensitive to the version of Go that is used. In
the past, formatting of source differed depending on the
version. Right now it is the content of the vendor directory which
changes when switch back and forth between 1.12 and 1.13.
We don't want to impose a certain workflow on developers, like forcing
all invocations of Go to run inside a container. If developers want
that, they can set up their development environment accordingly.
But we should warn about this aspect to raise awareness. "make"
invocations which involve Go now compare against the projects Go
version (specified in travis.yml) once at the beginning. This is only
a warning because we don't know which future version will be
compatible with the project.
Vendor directory handling gets updated, too: verification is now a
separate script (became too complex for make) and there is a
corresponding "update-vendor.sh". In contrast to verification,
updating vendor is not integrated into make and thus itself invokes
the go version check.
It turned out that changes like
https://github.com/kubernetes-csi/csi-lib-utils/pull/33 should better
have been committed after `go mod tidy` because that adds some
indirect dependencies in that example.
The revised `test-vendor` checks for that and (just in case that this
ever becomes desired) allows projects to not have a vendor directory
when using `go mod`.
How to use `go mod` properly gets documented in the README.md, because
there are such pitfalls.
How a repo does vendoring is detected based on the presence of
Gopkg.toml.
The vendor check with `dep` was all done locally, but the
corresponding check for `go mod` requires network access. The check
therefore gets skipped when running in the Prow CI in situations where
we are sure that it isn't needed (for example, in a periodic job).
By default this only tests the scripts inside the "release-tools"
directory, which is useful when making experimental changes to them in
a component that uses csi-release-tools. But a component can also
enable checking for other directories.
The introduction for each individual test looked like an actual
command:
test-subtree
./release-tools/verify-subtree.sh release-tools
Directory 'release-tools' contains non-upstream changes:
...
It's better to make it look like a shell comment and increase its
visibility with a longer prefix:
### test-subtree:
./release-tools/verify-subtree.sh release-tools
...
Individual repos may have to filter out certain packages from
testing. For example, in csi-test the cmd/csi-sanity directory
contains a special test that depends on additional parameters that set
the CSI driver to test against.
"make test" used to abort after the first test failure. That was
partly intentional: if the simple tests already fail (for example,
because of a syntax error), then there is no point in continuing to
test.
However, it also makes it harder to find all errors in a CI system
when the errors are unrelated (first error shows up, gets fixed, next
error shows up, etc.).
Now "make test" still aborts early, but "make -k test" is used in the
CI and will run all individual tests because they are split up into
different targets.
Patrick Ohly
Aaron Crickenberger
andyzhangx
Abhisek Banerjee
Jan Wozniak
Michelle Au
Peeyush Gupta
Kubernetes Prow Robot
Deep Debroy
Pengzhi Sun