This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch camel-main
in repository https://gitbox.apache.org/repos/asf/camel-k.git
commit 166a521b0cc3a88f1848e8913b2653779b9359ec
Author: Tadayoshi Sato <sato.tadayo...@gmail.com>
AuthorDate: Fri Jun 11 18:28:38 2021 +0900
doc(e2e): refactor e2e doc and add usage of Nexus repo mirror in e2e
testing #2387
---
.../ROOT/pages/contributing/developers.adoc | 20 +---------
docs/modules/ROOT/pages/contributing/e2e.adoc | 44 ++++++++++++++++++++--
2 files changed, 42 insertions(+), 22 deletions(-)
diff --git a/docs/modules/ROOT/pages/contributing/developers.adoc
b/docs/modules/ROOT/pages/contributing/developers.adoc
index 75c47e4..3235716 100644
--- a/docs/modules/ROOT/pages/contributing/developers.adoc
+++ b/docs/modules/ROOT/pages/contributing/developers.adoc
@@ -87,27 +87,11 @@ make STAGING_IMAGE_NAME='docker.io/myrepo/camel-k'
images-push-staging
Unit tests are executed automatically as part of the build. They use the
standard go testing framework.
Integration tests (aimed at ensuring that the code integrates correctly with
Kubernetes and OpenShift), need special care.
-
-The **convention** used in this repo is to name tests `xxx_test.go`.
Integration tests are all in the
https://github.com/apache/camel-k/tree/main/e2e[/e2e] dir.
-Since both names end with `_test.go`, both would be executed by go during the
build, so you need to put a special **build tag** to mark
-integration tests. An integration test should start with the following line:
-
-[source]
-----
-// +build integration
-----
-
-Look into the https://github.com/apache/camel-k/tree/main/e2e[/e2e] directory
for examples of integration tests.
-
-Before running an integration test, you need to be connected to a
Kubernetes/OpenShift namespace.
-After you log in into your cluster, you can run the following command to
execute **all** integration tests:
+For more detail on integration testing, refer to the following documentation:
-[source]
-----
-make test-integration
-----
+- xref:contributing/e2e.adoc[End To End local integration test]
[[running]]
== Running
diff --git a/docs/modules/ROOT/pages/contributing/e2e.adoc
b/docs/modules/ROOT/pages/contributing/e2e.adoc
index aa46527..14ce676 100644
--- a/docs/modules/ROOT/pages/contributing/e2e.adoc
+++ b/docs/modules/ROOT/pages/contributing/e2e.adoc
@@ -2,24 +2,41 @@
Camel K has a suite of integration test that will run on every Pull Request.
You can contribute by adding an integration test to cover any new feature
introduced (or increment the coverage with features still untested).
-The test script will take care to install the operators needed in a random
namespace, execute all expected tests and clean themselves. Cleaning may not be
performed if the execution of tests fails or the test process is interrupted.
In that case you can look for any namespace similar to
`test-29ed8147-c9fc-4c04-9c29-744eaf4750c6` and remove manually.
+Since both unit test and integration test names end with `_test.go`, both
would be executed by go during the build, so you need to put a special **build
tag** to mark
+integration tests. An integration test should start with the following line:
+
+[source]
+----
+// +build integration
+----
+
+Look into the https://github.com/apache/camel-k/tree/main/e2e[/e2e] directory
for examples of integration tests.
-In order to run the test locally you will have to be connected to a kubernetes
cluster and execute:
+Before running an integration test, you need to be connected to a
Kubernetes/OpenShift namespace.
+After you log in into your cluster, you can run the following command to
execute **all** integration tests:
+[source]
----
-make test
+make test-integration
----
+The test script will take care to install the operators needed in a random
namespace, execute all expected tests and clean themselves. Cleaning may not be
performed if the execution of tests fails or the test process is interrupted.
In that case you can look for any namespace similar to
`test-29ed8147-c9fc-4c04-9c29-744eaf4750c6` and remove manually.
+
+[[testing-operator]]
+== Testing Operator under development
+
You probably want to test your changes on camel-k `operator` locally after
some development. You will need to make the operator docker image available to
your cluster registry before launching the tests. We have a script that will
take care of that.
First, you must connect and point to the `docker daemon`. If you're on a local
environment such as `minikube`, it will be as simple as executing
+[source]
----
eval $(minikube -p minikube docker-env)
----
For other cluster types you may check the specific documentation. As soon as
you're connected to the `docker daemon` you can build images via:
+[source]
----
make images
----
@@ -28,6 +45,25 @@ The script will take care to build the operator docker image
and push to the und
You can also execute the following script, if by any chance you have some
change applied to the `camel-k-runtime`:
+[source]
----
make images-dev
-----
\ No newline at end of file
+----
+
+[[using-nexus]]
+== Using Nexus repository mirror with E2E testing
+
+To speed up integration testing locally, you may use a
https://github.com/sonatype/docker-nexus3[Nexus Repository Manager] for Maven
repository mirror.
+
+You can set the environment variable `TEST_ENABLE_NEXUS=true` to enable the
usage of Nexus mirror in e2e testing. If `TEST_ENABLE_NEXUS` is set, e2e tests
will try to discover an Nexus instance as `nexus` service in `nexus` namespace
and if it is found they will use it as the Maven repository mirror for the
`camel-k` platform under test.
+
+[source]
+----
+TEST_ENABLE_NEXUS=true make test-integration
+----
+
+To set up a Nexus instance in your cluster, run the following command:
+[source]
+----
+kubectl apply -f e2e/support/files/nexus.yaml
+----
