This change creates a new file with e2e testing documentation for the
new kubetest2 test runner. Once kubetest is retired, this can drop
right into the existing e2e developer guide docs.
This change removes the installation instructions for kubetest
in favor of links to the project documentation. The reason for this
change is that the installation instructions are no longer current for
the project, this removal will aid with a de-duplication of information.
According to the test-infra issue, some people seem to face the issue
when downloading kubetest command. So this adds NOTE to know how to
avoid the issue at this time.
If a test impacts other workloads in a meaningful way it ought
to be considered disruptive. Clarified the wording so that it
isn't so focused on only restarting components.
The default python on my system is python3. This caused me to run into
https://github.com/bazelbuild/rules_docker/issues/454 when running
`bazel build //...`. Update the documentation to indicate that
`/usr/bin/env python` must resolve to python2 in order for all of the
Bazel commands included in the documentation to work.
We can remove this comment after Bazel better supports using python3 as
the default system python. It appears from
https://github.com/bazelbuild/rules_docker/issues/580 that the
`rules_docker` folks hope to merge the fix in mid to late Q1 2019.
Previously, information on running unit and integration tests lived in
the testing.md doc, while information on running e2e tests lived in its
own doc. The testing.md doc is getting large, and particularly since its
a doc that many new members of the project look at, I think there's a
lot of benefit to keeping it concise.
To accomplish this, move information around running integration tests
into integration-tests.md, and then link to said document from
testing.md. This allows a new member of the project to get up and
running with unit tests, and then explore integration/e2e testing as
they have the need.
Improve the testing documentation in the following ways:
1. Ensure all of the given commands actually work. Some of them
specified tests that no longer existed or packages that no longer had
tests.
2. Clarify the ability to run tests for a package and all its
subpackages with `/...`.
3. Clarify how the developer can also utilize `go test` if they desire.
It looks like some links were not updated when `devel/sig-testing` was
created and populated with documentation.
Additionally, move `gubernator-images` to `devel/sig-testing`, as only
the `gubernator.md` file uses these images, and it now lives in
`devel/sig-testing`.
Michael McCune
Erik L. Arneson
SataQiu
Kubernetes Prow Robot
markyjackson-taulia
Stephen Heywood
Brian Pursley
Maru Newby
Robert Kielty
Kenichi Omichi
Martin Rey
mattjmcnaughton
Aaron Crickenberger
Spencer Thomas
Devan Carpenter
Caleb Woodbine
John Belamaric
John Schnake
Muneyuki Noguchi
Mark Janssen
Jordan Liggitt
Betula-L
Hannes Hörl
Maria Ntalla
toyoda
Nikhita Raghunath
eduartua