:linkattrs:
= Gerrit Code Review - End to end load tests

This document provides a description of a Gerrit load test scenario implemented using the
link:https://gatling.io/[Gatling,role=external,window=_blank] framework.

Similar scenarios have been successfully used to compare performance of different Gerrit versions
or study the Gerrit response under different load profiles.

== What is Gatling?

Gatling is a load testing tool which provides out of the box support for the HTTP protocol.
Documentation on how to write an HTTP load test can be found
link:https://gatling.io/docs/current/http/http_protocol/[here,role=external,window=_blank].

However, in the scenario we are proposing, we are leveraging the
link:https://github.com/GerritForge/gatling-git[Gatling Git extension,role=external,window=_blank]
to run tests at Git protocol level.

Gatling is written in Scala, but the abstraction provided by the Gatling DSL makes the scenarios
implementation easy even without any Scala knowledge. The
link:https://gitenterprise.me/2019/12/20/stress-your-gerrit-with-gatling/[Stress your Gerrit with Gatling,role=external,window=_blank]
blog post has more introductory information.

Examples of scenarios can be found in the `e2e-tests` directory. The files in that directory
should be formatted using the mainstream
link:https://plugins.jetbrains.com/plugin/1347-scala[Scala plugin for IntelliJ,role=external,window=_blank].
The latter is not mandatory but preferred for `sbt` and Scala IDE purposes in this project.

== How to build the tests

An link:https://www.scala-sbt.org/download.html[sbt-based installation,role=external,window=_blank]
of link:https://www.scala-lang.org/download/[Scala,role=external,window=_blank] is required.

The `scalaVersion` used by `sbt` once installed is defined in the `build.sbt` file. That specific
version of Scala is automatically used by `sbt` while building:

----
sbt compile
----

The following warning, if present when executing `sbt` commands, can be removed by creating the
link:https://www.scala-sbt.org/1.x/docs/Using-Sonatype.html#step+3%3A+Credentials[related credentials file,role=external,window=_blank]
locally. Dummy values for `user` and `password` in that file can be used initially.

----
[warn] Credentials file ~/.sbt/sonatype_credentials does not exist
----

Every `sbt` command can include an optional log level
link:https://www.scala-sbt.org/1.x/docs/Howto-Logging.html#Change+the+logging+level+globally[argument,role=external,window=_blank].
Below, `[info]` logs are no longer shown:

----
sbt --warn compile
----

=== How to build using Docker

----
docker build . -t e2e-tests
----

== How to set-up

=== SSH keys

If you are running SSH commands, the private keys of the users used for testing need to go in
`/tmp/ssh-keys`. The keys need to be generated this way (JSch won't validate them
link:https://stackoverflow.com/questions/53134212/invalid-privatekey-when-using-jsch[otherwise,role=external,window=_blank]):

----
mkdir /tmp/ssh-keys
ssh-keygen -m PEM -t rsa -C "test@mail.com" -f /tmp/ssh-keys/id_rsa
----

The public key in `/tmp/ssh-keys/id_rsa.pub` has to be added to the test user(s) `SSH Keys` in
Gerrit. Now, the host from which the latter runs may need public key scanning to become known.
This applies to the local user that runs the forthcoming `sbt` testing commands. An example
assuming `localhost` follows:

----
ssh-keyscan -t rsa -p 29418 localhost > ~/.ssh/known_hosts
----

=== Input file

The `CloneUsingBothProtocols` scenario is fed with the data coming from the
`src/test/resources/data/CloneUsingBothProtocols.json` file. Such a file contains the commands and
repository used during the load test. That file currently looks like below. This scenario serves
as a simple example with no actual load in it. It can be used to test or validate the local setup.
More complex scenarios can be further developed, under the `com.google.gerrit.scenarios` package.

----
[
  {
    "url": "ssh://admin@localhost:29418/loadtest-repo",
    "cmd": "clone"
  },
  {
    "url": "http://localhost:8080/loadtest-repo",
    "cmd": "clone"
  }
]
----

Valid commands are:

* `fetch`
* `pull`
* `push`
* `clone`

The example above assumes that the `loadtest-repo` project exists in the Gerrit under test.

== How to run tests

Run all tests:
----
sbt "gatling:test"
----

Run a single test:
----
sbt "gatling:testOnly com.google.gerrit.scenarios.CloneUsingBothProtocols"
----

Generate the last report:
----
sbt "gatling:lastReport"
----

The `src/test/resources/logback.xml` file
link:http://logback.qos.ch/manual/configuration.html[configures,role=external,window=_blank]
Gatling's logging level.

=== How to run using Docker

----
docker run -it e2e-tests -s com.google.gerrit.scenarios.CloneUsingBothProtocols
----

GERRIT
------
Part of link:index.html[Gerrit Code Review]

SEARCHBOX
---------

[scala]: