Reconcile testing docs, fixes #18606
This commit is contained in:
@@ -294,109 +294,7 @@ hack/test-integration.sh
|
||||
|
||||
## End-to-End tests
|
||||
|
||||
You can run an end-to-end test which will bring up a master and two nodes, perform some tests, and then tear everything down. Make sure you have followed the getting started steps for your chosen cloud platform (which might involve changing the `KUBERNETES_PROVIDER` environment variable to something other than "gce".
|
||||
|
||||
```sh
|
||||
cd kubernetes
|
||||
hack/e2e-test.sh
|
||||
```
|
||||
|
||||
Pressing control-C should result in an orderly shutdown but if something goes wrong and you still have some VMs running you can force a cleanup with this command:
|
||||
|
||||
```sh
|
||||
go run hack/e2e.go --down
|
||||
```
|
||||
|
||||
### Flag options
|
||||
|
||||
See the flag definitions in `hack/e2e.go` for more options, such as reusing an existing cluster, here is an overview:
|
||||
|
||||
```sh
|
||||
# Build binaries for testing
|
||||
go run hack/e2e.go --build
|
||||
|
||||
# Create a fresh cluster. Deletes a cluster first, if it exists
|
||||
go run hack/e2e.go --up
|
||||
|
||||
# Create a fresh cluster at a specific release version.
|
||||
go run hack/e2e.go --up --version=0.7.0
|
||||
|
||||
# Test if a cluster is up.
|
||||
go run hack/e2e.go --isup
|
||||
|
||||
# Push code to an existing cluster
|
||||
go run hack/e2e.go --push
|
||||
|
||||
# Push to an existing cluster, or bring up a cluster if it's down.
|
||||
go run hack/e2e.go --pushup
|
||||
|
||||
# Run all tests
|
||||
go run hack/e2e.go --test
|
||||
|
||||
# Run tests matching the regex "Pods.*env"
|
||||
go run hack/e2e.go -v -test --test_args="--ginkgo.focus=Pods.*env"
|
||||
|
||||
# Alternately, if you have the e2e cluster up and no desire to see the event stream, you can run ginkgo-e2e.sh directly:
|
||||
hack/ginkgo-e2e.sh --ginkgo.focus=Pods.*env
|
||||
```
|
||||
|
||||
### Combining flags
|
||||
|
||||
```sh
|
||||
# Flags can be combined, and their actions will take place in this order:
|
||||
# -build, -push|-up|-pushup, -test|-tests=..., -down
|
||||
# e.g.:
|
||||
go run hack/e2e.go -build -pushup -test -down
|
||||
|
||||
# -v (verbose) can be added if you want streaming output instead of only
|
||||
# seeing the output of failed commands.
|
||||
|
||||
# -ctl can be used to quickly call kubectl against your e2e cluster. Useful for
|
||||
# cleaning up after a failed test or viewing logs. Use -v to avoid suppressing
|
||||
# kubectl output.
|
||||
go run hack/e2e.go -v -ctl='get events'
|
||||
go run hack/e2e.go -v -ctl='delete pod foobar'
|
||||
```
|
||||
|
||||
## Local clusters
|
||||
|
||||
It can be much faster to iterate on a local cluster instead of a cloud-based one. To start a local cluster, you can run:
|
||||
|
||||
```sh
|
||||
# The PATH construction is needed because PATH is one of the special-cased
|
||||
# environment variables not passed by sudo -E
|
||||
sudo PATH=$PATH hack/local-up-cluster.sh
|
||||
```
|
||||
|
||||
This will start a single-node Kubernetes cluster than runs pods using the local docker daemon. Press Control-C to stop the cluster.
|
||||
|
||||
### E2E tests against local clusters
|
||||
|
||||
In order to run an E2E test against a locally running cluster, use the `e2e.test` binary built by `hack/build-go.sh`
|
||||
directly:
|
||||
|
||||
```sh
|
||||
export KUBECONFIG=/path/to/kubeconfig
|
||||
e2e.test --host=http://127.0.0.1:8080
|
||||
```
|
||||
|
||||
To control the tests that are run:
|
||||
|
||||
```sh
|
||||
e2e.test --host=http://127.0.0.1:8080 --ginkgo.focus="Secrets"
|
||||
```
|
||||
|
||||
## Conformance testing
|
||||
|
||||
End-to-end testing, as described above, is for [development
|
||||
distributions](writing-a-getting-started-guide.md). A conformance test is used on
|
||||
a [versioned distro](writing-a-getting-started-guide.md).
|
||||
|
||||
The conformance test runs a subset of the e2e-tests against a manually-created cluster. It does not
|
||||
require support for up/push/down and other operations. To run a conformance test, you need to know the
|
||||
IP of the master for your cluster and the authorization arguments to use. The conformance test is
|
||||
intended to run against a cluster at a specific binary release of Kubernetes.
|
||||
See [conformance-test.sh](http://releases.k8s.io/HEAD/hack/conformance-test.sh).
|
||||
See [End-to-End Testing in Kubernetes](e2e-tests.md).
|
||||
|
||||
## Testing out flaky tests
|
||||
|
||||
|
Reference in New Issue
Block a user