Merge branch 'stable-3.2' into stable-3.3 * stable-3.2: e2e-tests: Add in-depth instructions on how to execute gatling tests Change-Id: I7b1a908f3b8105777f848dde463bfe020e16d315
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 -```