The repo was created with an HTML version of the build.make file from
https://github.com/pohly/csi-build-rules/. Here's the raw file.

It's worth calling out explicitly that only the master branch is
maintained.

The actual repository was not named like the prototype repo.

initial content

Copy-and-paste error from the time when the
kubernetes-csi/csi-release-tools repo didn't have the code...

README.md: fix repo URL for initial setup

The goal is to enforce that changes get merged upstream first and only
get into the local repo via a normal "git subtree merge".

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

We don't want to allow local modifications in the subtree. Everything
should go to the csi-release-tools repo first.

check subtree for changes

This may or may not work, depending on which packages have tests and
whether they contain glog.

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.

After merging into external-attacher, the next Travis CI run did not
push the "canary" image because the check for "canary" only covered
the case where "-canary" is used as
suffix (https://travis-ci.org/kubernetes-csi/external-attacher/builds/484095261).

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

build.make: fix pushing of "canary" image from master branch

test enhancements

If for whatever reasons a repo already had a `release-tools` directory
before doing a clean import of it with `git subtree`, the check used
to fail because it found those old commits.

This can be fixed by telling `git log` to stop when the directory
disappears from the repo. There has to be a commit with removes the
old content, because otherwise `git subtree add` doesn't work.

Fixes: kubernetes-csi/external-resizer#21

verify-subtree.sh: relax check and ignore old content

In repos that have a test/e2e, that test suite should be run
separately because it depends on a running cluster.

This is an unmodified copy of kubernetes/hack/verify-shellcheck.sh
revision d5a3db003916b1d33b503ccd2e4897e094d8af77.

This runs "dep check" to verify that the vendor directory is
up-to-date and meets expectations (= done with dep >= 0.5.0).

check vendor directory

In repos that have a test/e2e, that test suite should be run
separately because it depends on a running cluster.

build.make: avoid unit-testing E2E test suite

These are the modifications that were necessary to call this outside
of Kubernetes. The support for excluding files from checking gets
removed to simplify the script. It shouldn't be needed, because
linting can be enabled after fixing whatever scripts might fail the
check.

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.

This enables testing of other repos and of this repo itself inside
Prow. Currently supported is unit testing ("make test") and E2E
testing (either via a local test suite or the Kubernetes E2E test
suite applied to the hostpath driver example deployment).

The script passes shellcheck and uses Prow to verify that for future
PRs.

verify shellcheck

The travis.yml is now the only place where the Go version for the
component itself needs to be configured.

Using the same (recent) Go version for all Kubernetes versions can
break for older versions when there are incompatible changes in Go. To
avoid that, we use exactly the minimum version of Go required for each
Kubernetes version. This is based on the assumption that this
combination was tested successfully.

When building the E2E suite from Kubernetes (the default) we do the
same, but still allow building it from elsewhere.

We allow the Go version to be empty when it doesn't matter.

While switching back and forth between release-1.13 and release-1.14
locally, there was the problem that the local kind image kept using
the wrong kubelet binary despite rebuilding from source. The problem
went away after cleaning the Bazel cache. Exact root cause unknown,
but perhaps using unique tags and properly cleaning the repo helps.

If not, then the unique tags at least will show what the problem is.

Instead of always using the latest E2E tests for all Kubernetes
versions, the plan now is to use the tests that match the Kubernetes
version. However, for 1.13 we have to make an exception because the
suite for that version did not support the necessary
--storage.testdriver parameter.

The temporary fork was merged, we can use the upstream repo again.

Prow testing

This ensures that also new, currently unknown alpha gates are enabled
when testing against a future Kubernetes versions. For all currently
known Kubernetes versions we just use the minimal set of alpha gates,
which ensures that we don't miss any of them in our documentation.

"grep -w" treated "serial-alpha" as two words and therefore
CSI_PROW_TESTS sometimes ran too many tests.

The previous logic failed for canary jobs, those also deploy a recent
driver. Instead of guessing what driver gets installed based on job
parameters, check what really runs in the cluster and base the
decision on that.

We only need to maintain this blacklist for 1.0.x until we replace it
with 1.1.0, then this entire hostpath_supports_block can be removed.

When running only some tests, sometimes extra, unnecessarily work was
done, like bringing up the cluster without alpha gates.

Not all environments have Docker. The simplifying assumption here is
that if the Docker command is available, it's also usable.

When KinD fails in a Prow job, we need additional information to
understand why it failed.

It turned out to not work. Instead of reverting the commit which
introduced this, let's better document this explicitly.

prow enhancements

This was already meant to be done earlier in cda2fc5.
While at it, extend the permanent TODO with guidance on future feature
gates.

prow.sh: remove AllAlpha=all, part II

build.make: Replace 'return' to 'exit' to fix shellcheck error

This pulls in
kubernetes-csi/csi-driver-host-path#37, which
turned out to be necessary for pre-submit testing of the
livenessprobe.

prow.sh: update csi-driver-host-path

Whether a component supports sanity testing depends on the
component. For example, csi-driver-host-path enables it because it
makes sense there (and only there). Letting the prow.sh script decide
whether it actually runs simplifies the job definitions in test-infra.

prow.sh: skip sanity testing if component doesn't support it

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 <[email protected]>

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 <[email protected]>

…kind-cluster

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

build windows binaries with .exe suffix

…pansion

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 <[email protected]>

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.