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.
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.
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: https://github.com/kubernetes-csi/external-resizer/issues/21
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
...
Maintaining a list of all the temp files used by various editors and
IDEs is cumbersome. Instead of doing that in each repo, developers
contributing to kubernetes-csi should set up a global .gitignore for
their own tools.
This synchronizes the build rules with other repos and (as part of
that) bumps the Go version to 1.11.1. The recommended formatting
changed slightly in that Go version.
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.
