The `find` tool has hard to comprehend syntax and does not consider
things excluded by .gitignore. I keep tripping over this in my own
repos, where I have __stuff which gets found.
This converts update-codegen to use `git ls-files` in a seemingly
equivalent way (`-cmo --exclude-standard`). I verified it finds the
same set of files as before.
This also drops some obsolete filtering.
Also hide grep errors for not-found files, which can happen if a file is
removed but git ls-files still knows it.
Re-running update-codegen shows no diffs.
This will make subsequent changes easier.
Don't just grep for DO NOT EDIT - anchor it in something that looks like
a comment and alone on a line.
Also ignore __* dirs
Prevent it from triggering on update-generated-swagger-docs (hack, but
better than before)
The env vars are needed until go workspaces lands, then it can get
simpler.
Downsides to this:
1) If you don't call kube::golang::setup_env, it might work but will
just splat results somewhere
2) The resultant binaries are not in _output/bin but instead in the
phony GOPATH/bin (which setup_env puts in PATH)
hack/pin-dependency.sh github.com/moby/ipvs v1.1.0
- go to a fixed tag for `vishvananda/netns`
- no more references to `pkg/errors`
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
This came up when updating go-oidc. After updating go-oidc (with its
dependency tree), cloud.google.com/go was no longer used as a package
import, but still listed in the module dependency graph; as a result,
"go mod vendor" no longer pulled in cloud.google.com/go itself, but
update-vendor-licenses.sh still wanted a license file for it since it
appeared in the list of modules.
This scenario is already supposed to be handled: when a module doesn't
contain any *files* as first-level content, if the number of
subdirectories it contains *equals* the number of submodules it
contains (excluding itself), the module is skipped. This fails for
cloud.google.com/go because several submodules are included in the
module dependency graph but aren't actually used, and therefore not
vendored.
Updating the test to check that the number of subdirectories is less
than or equal to the number of expected submodules fixes this.
The correct fix would be to process the submodules first, keeping a
note of which ones really have content, then check that the top-level
module only contains subdirectories corresponding to those modules;
but it's not clear to me that this is worth the effort (especially in
a shell script).
Signed-off-by: Stephen Kitt <skitt@redhat.com>
From the warning message that ginkgo now emits:
--slow-spec-threshold is deprecated --slow-spec-threshold has been deprecated
and will be removed in a future version of Ginkgo. This feature has proved
to be more noisy than useful. You can use --poll-progress-after, instead, to
get more actionable feedback about potentially slow specs and understand
where they might be getting stuck.
We already use --poll-progress-after.
This is a fix for 104aab81a4: because
the default was not set for E2E_TEST_DEBUG_TOOL, all parameters were always
also passed to the E2E suite.
That wasn't wrong for the parameters so far, but breaks when using something
like --output-dir which is only understood by the CLI.
If the script was called with no arguments, it passed "${@:-}" to the suite,
which expands to one empty argument. That's not right, "${@}" should be used
instead because it expands to nothing when empty.
