1) Fail if we can't read critical env vars
2) Don't rely on KUBE_ROOT env var when `go list` works
3) Don't rely on GOOS env var when `go env` works
4) Don't quietly ignore "can't read" errors
Once we stop ignoring errors, some tests fail for real (and should
always have failed).
The "Imported k8s.io/staging constant" test seems to not be allowed at
all anymore. Han said to nix it and he'd look async.
Oversall this test is dodgy. You REALLY can't glue strings together and
expect valid Go module paths. We should consider a deeper rework.
There's no easy way to make it work in the new model. Callers add flags
to the commandline like:
```
"${CODEGEN_PKG}/generate-internal-groups.sh" "client,conversion,deepcopy,defaulter,informer,lister,openapi" \
k8s.io/code-generator/examples/apiserver \
k8s.io/code-generator/examples/apiserver/apis \
k8s.io/code-generator/examples/apiserver/apis \
"example:v1 example2:v1 example3.io:v1" \
--output-base "${SCRIPT_DIR}/../../../.." \
--go-header-file "${SCRIPT_DIR}/boilerplate.go.txt"
```
To support this we would need to parse these flags in these scripts and
try to adapt them to the new CLI tool interfaces. Not impossible, but
seeing as we deprecated these a few releases ago AND that we have other
breaking changes to the tools, let's just rip this bandaid off?
Now that they all call setup_env, we don't need find-binary (I think).
That was originally meant to hide the diff between docker and local
builds but all these tools do local builds anyway.
* Moved code and tests out of gengo -> code_generator
* Reworked it to use packages.Load
* Reworked tests (still not comprehensive but pretty good?)
* Dropped test support from gengo (support for tests in
x/tools/go/packages is pretty hostile to gengo, and nobody used it)
Instead of walking paths ourselves, just let Go's packages library do
it. This is a slight CLI change - it wants "./foo" rather than "foo".
This also flagged a few things which seem to be legit failures.
