Before we get too many suites baked, I want to get spec randomization
in, just so no one accidentally thinks things flow from top to bottom.
The random seed is printed with every run:
Random Seed: 1423194521 - Will randomize all specs
and can be reproduced using --ginkgo.seed
* Add a test/e2e/shell.go that slurps up everything in hack/e2e-suite
and runs it as a bash test, borrowing all the code from hack/e2e.go.
* Rip out all the crap in hack/e2e.go that deal with multiple tests
* Move hack/e2e-suite/goe2e.sh to hack/ginkgo-e2e.sh so that it
doesn't get slurped up.
This will allow us greated isolation between test case runs without the
need to include randomized uuids to many of the fields in the pods,
services and rcs creation requests.
Tested:
- Ran two instances of `e2e -t TestLivenessHttp -t TestLivenessExec`
simultaneously and confirmed that pod names did not clash and that
both of them completed successfully.
Start to use unique names for the pods and services. Later, we will
replace that by the use of namespaces.
We are also discussing using a versioned api, however that refactor can
happen on a follow up commit as well.
Tested by running cmd/e2e -t Pods against an API server in GCE.
This is another step in removing external dependencies of the Go e2e tests.
Remove references to this file on list of files required to run e2e tests.
Also use an unique name for the pod, so that failure in cleanup of a
previous run should not break a new run with a name conflict.
Tested by running cmd/e2e -t TestPodUpdate against an API server in GCE.
This is another step in removing external dependencies of the Go e2e tests.
Also remove other references to this file.
Tested by running cmd/e2e -t TestKubeletSendsEvent against an API server in GCE.
Avoid importing the YAML files from the examples/ tree, instead just
define the api.Pod structs in the Go source code.
Tested by running the TestLivenessHttp and TestLivenessExec tests
against a test cluster.
Use the --ginkgo.focus flag which accepts a regexp to define which tests
should be run. Create a regexp matching a full word that is exactly one
of the test names passed as -t parameters.
Tested with cmd/e2e -t TestLivenessHttp -t TestLivenessExec, confirmed
that 2 tests were executed and 9 were skipped.
Instead of forcing the NoColor flag to on at runtime, make it default to
being on in a way that it's still possible to override it by passing e2e
the --ginkgo.noColor=false command-line flag.
Tested by running the tests with and without the flag and confirming
that both worked as expected.
Use ginkgo's native support for JUnit in order to generate the XML file.
This is a first step in better integration of our e2e tests with
Jenkins. In order to improve the logged information, we will probably
need to have more native ginkgo tests but this step allows us to see
what Jenkins can already do with this information and what we need to
tweak to improve it.
Tested by running the full e2e tests and inspecting the contents of
junit.xml on the top of the tree.
Textual output is still generated on the console to keep the current
goe2e.sh logs available until the full conversion of our Jenkins
instance to use the JUnit XML is completed.
In order to adopt ginkgo incrementally, let's start by replacing
test/e2e/driver.go with a call to ginkgo runner and convert each of the
other tests to a small Decscribe() snippet that simply calls the legacy
TestXYZ function.
From this basis we can take further incremental steps by converting
individual tests to native ginkgo format, using Fail() for all failure
cases, using By() for logs, enabling JUnit reports, etc.
Tested:
- cmd/e2e builds and `make check` passes.
- Running _output/bin/.../e2e on an alive cluster works.
- Running the full hack/e2e-test.sh works as expected.
