E2E: handling extra files #69103
What this PR does / why we need it:
There is an on-going effort to make test/e2e.test self-contained by building all files that are needed at runtime into the binary via bindata. Tests which support that do so by retrieving files from the test/e2e/generated package. The downside of that approach is that such tests only work in Kubernetes itself. As described in issue #66649, making tests reusable outside of Kubernetes is useful, for example for testing other CSI drivers.
This PR adds an API (test/e2e/framework/testfiles) that decouples tests from the actual code that retrieves files. In the test/e2e test suite, access via --repo-root is kept in addition to retrieval from bindata, so everything works as before.
The goal is not to get rid of --repo-root. However, by converting some tests to use the new API, those tests no longer depend on --repo-root, so we get a step closer to that goal - if it still is a goal. Some tests depend on extra files (for example, test/e2e/framework/ingress/ingress_utils.go for providing the optional secret.yaml) which cannot be built into the binary.
Which issue(s) this PR fixes (optional, in
Special notes for your reviewer:
This depends on PR #68187 getting merged first. The first commit here is from that PR.
This is a subset of PR #68483.
@timothysc I force-pushed two commits, one for the source code changes and one for the Bazel BUILD files. I kept the test/e2e/examples.go changes because if we merge all of this at once, we do not need PR #68187 anymore.
This version uses
Here's output for a test that triggers such a panic because the file name was changed such that the file isn't found. I've shortened the list of files. The original error lists all of the builtin files:
@timothysc I pushed a version which takes a callback that gets invoked on failures. To make the API still easy to use, the signature is exactly that of ginkgo.Fail. Otherwise callers would have to use a closure.
Some callers can handle an error and don't use Ginkgo. For those I added a
There's also some test failure in pull-kubernetes-integration which I don't understand ("test-cmd run_rs_tests" fails) - a flake or does this PR really cause that test to fail now?
[APPROVALNOTIFIER] This PR is APPROVED
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing