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).

switch to Go 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.

Add steps on promoting release images

cloud build: bump timeout in Prow job

filter-junit: Fix gofmt error

Signed-off-by: Animesh Kumar <animuz111@gmail.com>

filter-junit: Fix golint error

Signed-off-by: Animesh Kumar <animuz111@gmail.com>

prow.sh: enable building arm64 image

cloud build: k8s-staging-sig-storage

As discussed in https://github.com/kubernetes/k8s.io/pull/943, we want
to consolidate under k8s-staging-sig-storage.

cloud build: initialize support for running commands in Dockerfile

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

multiarch windows fix

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.

It's not a real file and thus should better be marked as phony.

"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.

cloud build: initial set of shared files

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.

Update patch release notes generation command

Fix csi-snapshotter RBAC yaml version

Signed-off-by: Grant Griffiths <grant@portworx.com>

update release tools instructions

Update snapshotter to version 2.0.1

Signed-off-by: Grant Griffiths <grant@portworx.com>

build for multiple platforms only in CI, add s390x

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.

prow.sh: use 1.3.0 hostpath driver for testing

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.

Change 'make test-vet' back to call 'go vet'

prow.sh: generic driver installation

prow.sh: also configure feature gates for kubelet