this is handled centrally by make test which is called by make test-integration which this script calls
only make test's implementation actually calls gotestsum, and it also handles installing if needed
- stop setting ARTIFACTS from WORKSPACE, CI handles setting ARTIFACTS and WORKSPACE isn't used anymore (bazel?)
- stop cd-ing GOPATH, CI sets the working dir already and local users won't necessarily have GOPATH
- sop clobbering PATH with hardcoded assumptions, source install-etcd.sh instead (which updates PATH)
- don't redundantly set KUBE_COVER to the default
- pass logging env inline so the command can be pasted locally
- set -x so the command is visible
- add TODO about needing a wrapper script just to call install-etcd
The goal of compiling and running each suite was to check explicitly with a
clear failure message when test registration is faulty or the suite detects
some other issue. But the check is slow (> 4 minutes), probably because of the
compilation step.
This self-testing also happens when running the suites, so we can remove the
verify script. We loose some coverage for suite changes which don't run during
required presubmits (kubeadm?), but that seems acceptable.
These suppressions are necessary to make golangci-lint 1.64 pass with the
current code base. This change is meant to be backported to release
branches. On master, we may want to revert some of it together with fixing the
findings.
This enables testing command and integration tests separately in CI jobs. The
goal is to reduce pull-kubernetes-integration to testing really just the Go
test/integration tests and to add a pull-kubernetes-cmd job for command tests.
hack/jenkins/test-dockerized.sh does the same as before because some jobs will
probably continue to use it.
Kernels may have `kernel.dmesg_restrict = 1` set which requires root
access to see dmesg. We're now using `sudo` to mitigate that.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
The corresponding "pull-kubernetes-verify-lint" job was already removed
earlier. Manual strict checking was still possible, but doesn't really make
sense for the same reasons why the job was removed (e.g. the decisions which
checks should be "strict" were too arbitrary).
The explanations for "hints" no longer end with "In general please prefer to
fix the error, ..." because that was misleading and only really applied to the
checks for existing code. For those checks we prefer to fix errors instead of
suppressing them, but not for hints.
We have to cleanup the background job after the script otherwise we will
end up having them hanging around.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
