Merge branch 'stable-3.3'
* stable-3.3:
e2e-tests: Add in-depth instructions on how to execute gatling tests
Change-Id: I8830532e9fc565a6b8ab8431b9671cd5936bc6ba
diff --git a/src/test/README.md b/src/test/README.md
index c7a5225..1b8e4a2 100644
--- a/src/test/README.md
+++ b/src/test/README.md
@@ -1,8 +1,94 @@
-# About this directory structure
+# Gerrit high-availability docker setup example
-Refer to docker/README.md for more about these directory structures:
+The Docker Compose project in the docker directory contains a simple test
+environment of two Gerrit masters in HA configuration.
+
+## How to build
+
+The project can be built using docker-compose.
+
+To build the Docker VMs:
+```
+ $ docker-compose build
+```
+
+### Building the Docker VMs using a non-default user id
```
- ./resources/com
- ./scala
+ $ export GERRIT_UID=$(id -u)
+ $ docker-compose build --build-arg GERRIT_UID
+```
+
+Above, exporting that UID is optional and will be 1000 by default.
+Build the gerrit images this way only if the user with id 1000 on your
+host is not owned by you. For example, some corporate environments use a
+restricted 1000 user (id). In that case, the containerized application
+may fail to write towards the host (through volumes).
+
+That UID will be the one set for the containerized gerrit user. Latter's
+group will remain as default (1000). This is because groups known from
+the host need to be redefined for containers. Setting that user's group
+in the container is not necessary for writing anyway, as opposed to its
+user id. The individual gerrit user's writing permission does suffice.
+
+## How to run
+
+Use the 'up' target to startup the Docker Compose VMs.
+
+```
+ $ docker-compose up
+```
+
+# Gerrit high-availability local setup example
+
+ 1. Init gerrit instances with high-availability plugin installed:
+ 1. Optionally, set http port of those instance to 8081 and 8082.
+ 2. Make sure ssh ports on those instances are different. (i.e. 29418 and 29419)
+ 3. Make sure instances share the same git repo.
+ 4. Create and provide shared directory to those instances.
+ 2. Set up high-availability plugin.
+ 1. main.sharedDirectory = "the created shared directory above".
+ 2. peerInfo.strategy = static
+ 3. peerInfo "static".url = other_instance_url (i.e http://localhost:8081 or http://localhost:8082)
+
+## How to test
+
+Consider the
+[instructions](https://gerrit-review.googlesource.com/Documentation/dev-e2e-tests.html)
+on how to use Gerrit core's Gatling framework, to run non-core test
+scenarios such as this plugin one below:
+
+```
+ $ sbt "gatling:testOnly com.ericsson.gerrit.plugins.highavailability.scenarios.CloneUsingHAGerrit2"
+```
+
+This is a scenario that can serve as an example for how to start
+testing an HA Gerrit system. That scenario tries to clone a project
+created on gerrit 1 (port 8081) but from gerrit 2 (on 8082). The
+scenario therefore expects Gerrit HA to have properly synchronized
+the new project from 1 to 2. That project gets deleted after, here
+using HA Gerrit straight (through default http port 80).
+
+Scenario scala source files and their companion json resource ones are
+stored under the usual src/test directories. That structure follows the
+scala package one from the scenario classes. The core framework expects
+such a directory structure for both the scala and resources (json data)
+files.
+
+Alternatively, the TEST_HA script can be used to run Gatling tests which
+provides a minimum configuration to run the test.
+
+## How to stop
+
+Simply type CTRL+C on the window that started the environment
+and all the VMs will stop. Their state will be persisted and the next
+run will continue with the same data.
+
+## How to clean
+
+If you want to stop and cleanup all the previous state, use the 'down'
+target.
+
+```
+ $ docker-compose down
```
diff --git a/src/test/TEST_HA b/src/test/TEST_HA
new file mode 100755
index 0000000..ef6d4e2
--- /dev/null
+++ b/src/test/TEST_HA
@@ -0,0 +1,33 @@
+#!/bin/bash
+#
+# Example usage only-
+# 1. Locally sync plugin's scenarios to the core e2e-tests (assuming the plugin is located under gerrit's plugins
+# directory):
+# a. rsync -a src/test/scala/ ../../e2e-tests/src/test/scala/
+# b. rsync -a src/test/resources/ ../../e2e-tests/src/test/resources/data/
+# 2. Change to base core e2e-tests directory to execute ./TEST_HA (this executable file) in its own terminal.
+# 3. See [1] for how to start using JAVA_OPTS below; you may leave it empty for these sbt commands. For this plugin
+# there are some extra properties available:
+# a. -Dcom.ericsson.gerrit.plugins.highavailability.scenarios.cluster_port to use different http port to connect
+# to the cluster, by default port 80 is used. This option is needed to run tests locally without the need of
+# a load balancer.
+# b. -Dcom.ericsson.gerrit.plugins.highavailability.scenarios.http_port1 http port of the first high-availability
+# instance, by default its 8081.
+# c. -Dcom.ericsson.gerrit.plugins.highavailability.scenarios.http_port2 http port of the second
+# high-availability instance, by default its 8082.
+# 13. To be able to run high-availability gatling tests without a load-balancer locally, http_cluster property
+# needs to point to one of the high-availability instances.
+#
+# [1] https://gerrit-review.googlesource.com/Documentation/dev-e2e-tests.html#_environment_properties
+
+export GIT_HTTP_USERNAME="admin"
+export GIT_HTTP_PASSWORD="TODO"
+export JAVA_OPTS="
+"
+#-Dx=y \
+
+#sbt clean
+#sbt update
+sbt compile
+sbt "gatling:testOnly com.ericsson.gerrit.plugins.highavailability.scenarios.CloneUsingHAGerrit2"
+#sbt "gatling:lastReport"
diff --git a/src/test/docker/README.md b/src/test/docker/README.md
deleted file mode 100644
index 4604423..0000000
--- a/src/test/docker/README.md
+++ /dev/null
@@ -1,79 +0,0 @@
-# Gerrit high-availability setup example
-
-This Docker Compose project contains a simple test environment
-of two Gerrit masters in HA configuration.
-
-## How to build
-
-The project can be built using docker-compose.
-
-To build the Docker VMs:
-```
- $ docker-compose build
-```
-
-### Building the Docker VMs using a non-default user id
-
-```
- $ export GERRIT_UID=$(id -u)
- $ docker-compose build --build-arg GERRIT_UID
-```
-
-Above, exporting that UID is optional and will be 1000 by default.
-Build the gerrit images this way only if the user with id 1000 on your
-host is not owned by you. For example, some corporate environments use a
-restricted 1000 user (id). In that case, the containerized application
-may fail to write towards the host (through volumes).
-
-That UID will be the one set for the containerized gerrit user. Latter's
-group will remain as default (1000). This is because groups known from
-the host need to be redefined for containers. Setting that user's group
-in the container is not necessary for writing anyway, as opposed to its
-user id. The individual gerrit user's writing permission does suffice.
-
-## How to run
-
-Use the 'up' target to startup the Docker Compose VMs.
-
-```
- $ docker-compose up
-```
-
-## How to test
-
-Consider the
-[instructions](https://gerrit-review.googlesource.com/Documentation/dev-e2e-tests.html)
-on how to use Gerrit core's Gatling framework, to run non-core test
-scenarios such as this plugin one below:
-
-```
- $ sbt "gatling:testOnly com.ericsson.gerrit.plugins.highavailability.scenarios.CloneUsingHAGerrit2"
-```
-
-This is a scenario that can serve as an example for how to start
-testing an HA Gerrit system. That scenario tries to clone a project
-created on gerrit 1 (port 8081) but from gerrit 2 (on 8082). The
-scenario therefore expects Gerrit HA to have properly synchronized
-the new project from 1 to 2. That project gets deleted after, here
-using HA Gerrit straight (through default http port 80).
-
-Scenario scala source files and their companion json resource ones are
-stored under the usual src/test directories. That structure follows the
-scala package one from the scenario classes. The core framework expects
-such a directory structure for both the scala and resources (json data)
-files.
-
-## How to stop
-
-Simply type CTRL+C on the window that started the environment
-and all the VMs will stop. Their state will be persisted and the next
-run will continue with the same data.
-
-## How to clean
-
-If you want to stop and cleanup all the previous state, use the 'down'
-target.
-
-```
- $ docker-compose down
-```
