2. add a dummy file tools.go to force "go mod vendor" to see
code-generator as dependencies
3. add a script to update CRD
4. add a README to document CRD updating steps
run go mod tidy
update README
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>
Manually resolved a merge conflict for vendor/modules.txt. This cannot
be done via a rebase because that would destroy the git submodule
history of `csi-release-tools`.
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.
A simple "go mod init && go mod tidy && go mod vendor" was enough and
mostly seems to have picked the same revisions of the dependencies as
before. Notable exceptions are klog and gogo/protobuf.
preserveUnknownField set to false, comments updates, adding pull request annotation
more comment updates
VolumeSnapshot comments
rename to VolumeSnapshotClassName
adding license
It turned out that changes like
https://github.com/kubernetes-csi/csi-lib-utils/pull/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.
