Commit summary:
0979c09 prow.sh: fix E2E suite for Kubernetes >= 1.18
3b4a2f1 prow.sh: fix installing Go for Kubernetes 1.19.0
82d108a switch to Go 1.15
843bddc Add steps on promoting release images
It used to be necessary to override from where the E2E suite came on a
case-by-case basis (initially, testing was using a more recent suite
against an older Kubernetes). This should never become necessary again
and the lack of a specific entry for 1.18 already had the unintended
effect that Kubernetes 1.18 was tested with the suite from master, so
overall it is better to always use the E2E suite which matches
Kubernetes.
Kubernetes 1.19.0 uses Go 1.15, but refers to it as 1.15.0. This broke
both the check whether we need to install 1.15 (because "go version"
reports 1.15, which didn't match 1.15.0) and then downloading the
release archive (because the URL also only uses 1.15).
Go 1.15 was released and is the major version that Kubernetes 1.19.0
is going to use. There are probably bugs in the older 1.13.3 that were
fixed, so we should update.
For RWX volume, kubelet does not perform recursive ownership/permission
change. The heuristics that kubelet uses is being modified via -
https://github.com/kubernetes/enhancements/issues/1682
Having said that, for RWX volumes which are made available via NFS
protocol, using fsGroup is not recommended because if there are 2 pods
that are trying to use same volume but with different fsGroup then one
pod may lock out the other pod.
To avoid this, we must be able to set the folder permissions to 777.
This commit adds a cli option --mount-permissions, that allows to
define custom permissions. If the value is not specified, then default
permissions will be kept.
Cherry-picked from: https://github.com/kubernetes-csi/csi-driver-nfs/pull/36
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
Commit summary:
340e082 build.make: optional inclusion of Windows in multiarch images
5231f05 build.make: properly declare push-multiarch
4569f27 build.make: fix push-multiarch ambiguity
bd41690 cloud build: initial set of shared files
6f2322e Update patch release notes generation command
d8c76fe Support local snapshot RBAC for pull jobs
ea1f94a update release tools instructions
7edc146 Update snapshotter to version 2.0.1
3863a0f build for multiple platforms only in CI, add s390x
7c5a89c prow.sh: use 1.3.0 hostpath driver for testing
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.
