Kubernetes also requires 1.12. We pick the latest stable release
for CI builds.

update to Go 1.12.4

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

build.make: allow repos to use 'go mod' for vendoring

By moving the code into a separate function, other CSI drivers have a
chance to overwrite it. For the hostpath driver itself we need the
ability to set the driver name depending on which revision is getting
installed.

more flexible test driver config

with specific patch versions that kind 0.4.0 supports. Also, feature
gate setting is only supported on 1.15+ due to
kind.sigs.k8s.io/v1alpha3 and kubeadm.k8s.io/v1beta2 dependencies.

Add 1.15 jobs

prow.sh: tag master images with a large version number

changes to kind. There are 3 changes made to prow.sh:

1. Use a master commit of kind that includes the fix for Kubernetes
master.
2. Use git clone instead of git checkout (shallow) to source Kubernetes.
This lets kind correctly figure out the Kubernetes release tag.
3. Build kind with make install. The kind fix was not working correctly
when built with go build.

Fix CI jobs on Kubernetes master

Update kind to v0.5.0

Signed-off-by: Deep Debroy <ddebroy@docker.com>

Add rule for building Windows binaries

"make test-vendor" depends on dep if the current project uses
dep. Without it, the vendor directory checking was skipped under Prow.

prow.sh: install dep if needed

…h driver

Signed-off-by: Mucahit Kurt <mucahitkurt@gmail.com>

…ind-cluster

Create 2-node kind cluster since topology support is added to hostpath

build windows binaries with .exe suffix

…ansion

Enable hostpath expansion

It turned out that changes like
kubernetes-csi/csi-lib-utils#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.

This script handles the necessary "replace" statements and determines
which packages need to be updated in lockstep.

Signed-off-by: Deep Debroy <ddebroy@docker.com>

Build Windows only for amd64

update Go mod support

errors when the depth is exactly 50.

Do full git clones in travis

Add new variables for 1.16 and remove 1.13

This is the latest release. Updating is useful to ensure that we have
all of the latest fixes and enhancements.

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.

Go version 1.13, helper scripts

This avoids dependencies on the Go module cache or the upstream code
hosting.

prow.sh: use vendor directory if available

Depending on the error, those logs are needed to debug failures.

prow.sh: also log output of system containers

Inside a real Prow job it is better to clean up at runtime instead of leaving that to the Prow job cleanup code because the later sometimes times out.

Signed-off-by: Mucahit Kurt <mucahitkurt@gmail.com>

…eanup

delete kind cluster after tests run

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

Add snapshotter CRDs after cluster setup

Adding build for ppc64le

kind v0.6.0 appends the kubeconfig with the default config at
~/.kube/config.

Use kind v0.6.0

…ure can be tested. Test cases that test accessing volumes from multiple nodes need to be skipped

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

Enable topology testing with hostpath driver

…ersion_gt

Improve snapshot-controller running check and version_gt to support multiple formats

fix syntax for ppc64le build

Improve README by adding an explicit Kubernetes dependency section

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.

Enable snapshot tests in 1.17 to be run in non-alpha jobs.

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

…netes_fix

Fix version_gt to work with Kubernetes prefix

Update prow hostpath driver version to 1.3.0-rc2

Fix overriding of junit results

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

…rsion_update

Update snapshotter to version v2.0.0

Update hostpath driver version to get fix for connection-timeout

Document the process for releasing a new sidecar

fix incorrect link

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.

That this hasn't been done before is an oversight. Apparently it
hasn't been a problem because there never have been feature gates that
mattered?

prow.sh: also configure feature gates for kubelet

prow.sh: generic driver installation

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

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.

prow.sh: use 1.3.0 hostpath driver for testing

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.

build for multiple platforms only in CI, add s390x

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

…pdate

Update snapshotter to version 2.0.1

update release tools instructions

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

…ter_rbac_version_set

Fix csi-snapshotter RBAC yaml version

Update patch release notes generation 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.

cloud build: initial set of shared files

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