This is a follow-up for commit beb51e1 ("make verify: run checks in
all module hack directories"). Checking only modules known to go ends
up ignoring modules which aren't dependencies, such as
./staging/src/k8s.io/code-generator/examples/hack; but the checks
should be run there too. So this finds modules by looking for go.mod
files.
Use PWD in run-checks to record failing verification scripts instead
of a hidden dependency on an externally-set variable.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
The pull-kubernetes-verify job is using this to run the base
verify-golangci.sh only in the pull-kubernetes-verify-lint job.
Because the file name was not quite right, it still ran.
Instead of invoking verify-golangci-lint.sh directly from Prow jobs,
those Prow jobs should use "make verify WHAT=...". The advantage is
that the common code for running verify targets will be used, which
includes producing JUnit files.
Providing simple wrappers for strict linting of PRs (=
verify-golangci-lint-pr.sh) and event stricter linting of PRs with hints
enabled (= verify-golangci-lint-pr-hints.sh) enables those WHAT targets.
When sh2ju.sh was called to generate the junit_verify.xml, it used to include
the entire output of a failed script twice: once as failure message, once as
log output.
This output can be large and often the actual failure isn't near the top, but
rather at the end or (in the case of the different golangci-lint invocations)
embedded in the log. This makes them hard to see at a glance when looking at
the Prow result page for a job.
Now a verify script can prefix relevant lines with "ERROR: " and then only
those lines are used as failure message in JUnit, without that prefix.
That string was chosen because Prow itself also then picks up those lines when
viewing the entire build log and it is unlikely that some script prints such
lines when they are not meant to be part of the failure.
If some script outputs no such lines, "see stderr for details" is used as
failure message. This is better than before because it avoids the redundancy.
The long-term goal is that when "make verify" is invoked in pull job, it will
also run golangci-lint with the strict configuration and write an
$ARTIFACTS/golangci-lint-githubactions.log file with GitHub actions
annotations. How to get those published for the GitHub PR is open.
When "make verify" is invoked manually or in any other job, the stricter check
will be skipped. That works because "PR_NUMBER" is only set for pre-merge
jobs (https://github.com/kubernetes/test-infra/blob/master/prow/jobs.md#job-environment-variables).
Because strict linting is still new and might not be useful without a better
UI (= GitHub annotations), this PR does not fully enable the integration into
"make verify". Instead, the new verify-golangci-lint-pr.sh is excluded from it
and needs to be run in a separate job.
Running logcheck as part of golangci-lint has several advantages:
- faster checking because finding files and parsing is shared
with other linters
- gets rid of the complex and buggy
hack/verify-structured-logging.sh (https://github.com/kubernetes/kubernetes/issues/106746)
- support for // nolint:logcheck
- works with Go 1.18
verify-publishing-bot is experiencing errors importing pyyaml since
python3 was added to kubekins-e2e image. This changes make verify to run
verify-publishing-bot with python3.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
- remove update_owners.py; seems responsible for generating
test_owners files
- remove the existing test/test_owners.* files
- remove verify-test-owners.sh and references to it
- Added scripts for update and verify
- golang AST code for scanning and fixing imports
- default regex allows it to run on just test/e2e.* file paths
- exclude verify-import-aliases.sh from running in CI jobs
Change-Id: I7f9c76f5525fb9a26ea2be60ea69356362957998
Co-Authored-By: Aaron Crickenberger <spiffxp@google.com>
