Before this change, the scala compiler issued warnings such as the one
below, upon using the usual 'sbt compile' command.
"(...) postfix operator second should be enabled
[warn] by making the implicit value scala.language.postfixOps visible.
[warn] This can be achieved by adding the import clause 'import scala.language.postfixOps'
[warn] or by setting the compiler option -language:postfixOps."
Set the latter option in build.sbt to remove these warnings. This is
less invasive than adding the aforementioned import clause in each file.
Bug: Issue 12288
Change-Id: If52dcddbcc63579602c788455a95c5e7d9009ee2
Align the gatling version used by the framework with the one used in
the gatling-git extension dependency.
This happens to fix the below issue, hence the reporting features.
Bug: Issue 12279
Change-Id: I63a8642ec71caaf2af5bcb12d54b94ff89e21bee
Make the core resources data file structure consistent with the one used
to add non-core scenario files in.
Modify the documentation accordingly.
Change-Id: Ic352488a81cc43211fa38f0f2454b4fa944e9da6
Document how to locally add non-core scenarios, for example from Gerrit
plugins, to then run them like regular core scenarios.
Include the companion .gitignore files, meant for the involved
destination folders.
Make the test data feeders private to scenarios now, while still reusing
the standard resource paths. This is to support non-core scenarios,
which require their resource path to slightly differ from core's. This
is so that non-core scenario resource files can be git-ignored when
added in, as per this change. Doing so also paves the way for more
structured resource data files based on scala package.
Change-Id: I499f9ed4765f64cf757aa244e427d7116c80d321
Add the CreateProject and DeleteProject scenarios and have the
CloneUsingBothProtocols scenario compose them. Make that scenario and
potential similar ones no longer require project creation outside of
them. Delete the project created by that scenario once done with it.
Clarify how to set the necessary http credentials in the documentation.
Refactor the GitSimulation class to fit with the hereby introduced
GerritSimulation one. The latter is meant to cover all things Gerrit,
including the added http support, while the former now only adds the git
specific harness to that.
Adapt ReplayRecordsFromFeeder accordingly, without adding create/delete
project support to that scenario yet. This can be done through another
change once needed.
Change-Id: Ifa72b7657c709266aca05cedb1e38d5e7fe4cd81
Move the contents of the former load-tests directory to the root of this
structure. Before this change, that directory was the only file set
present in this e2e-tests root structure.
This removal also paves the way for potential non-load e2e tests, such
as functional feature ones. Gerrit already has unit and acceptance or
(partial) integration tests for its functionality. However organizations
still need to internally develop and maintain -thus duplicate- full e2e
integration tests. E.g., to smoke-test new release deployment acts for
either development, staging or production purposes.
This change then also proposes to consider reusing this Gatling
framework (DSL, protocols) for e2e feature integration tests, alongside
the emerging load ones -for Gerrit.
Change-Id: Idffa7f43b546d6bfdc5d7b170d8ddc6c51b095c3
Remove code duplication between the two scenario classes that way.
Foster future framework reusability through such initial reuse.
Bug: Issue 12281
Change-Id: I1e474901b2acc12554c0bb202456183a7a7a5e7e
While aligning it with CloneUsingBothProtocols, i.e.:
- Extract the duplicated path into a reused local value.
- Move the Thread.sleep out of the try block.
- Remove the comment as it will come back in case of failure.
Next refactoring step(s) then: to extract duplication from these two
sibling scenario classes. Likely by means of introducing a common parent
class, as an intermediary between these two and their Simulation parent.
This is so the framework becomes more and more reusable and extensible.
Change-Id: I20eab87b4b533c356b1831fa346a1df4fce14729
With the sibling CloneUsingBothProtocols class. Rename the related value
members accordingly. Replace the hardcoded scenario name with the
previously generalized member value; reuse it further.
Rename the related protocol value member while being at it. Move these
renamed value members so they appear as in CloneUsingBothProtocols.
Change-Id: Icd9b53a2326488eb3f76a7739e995f398e4937a9
Remove the Scenario suffix from the class name, as that class is already
in the scenarios package; redundant otherwise. Align the file name with
the name of this class.
Change-Id: Ieab4b0cc6c89017e449b1520a5f7d4c234da50eb
Add the CloneUsingBothProtocols scenario class with its json file
companion. Propose a reusable way to code such classes, at least
initially, through that example class and json. Keep the corresponding
refactoring of their sibling ReplayRecordsFromFeederScenario files for
follow-up changes.
Use that simple and no-load CloneUsingBothProtocols scenario in the
documentation. Foster using that one instead to validate local setups.
As one's local setup gets tested that way, foster developing more
scenarios.
Change-Id: I39fae723a81633a49327e509a99269ba028dcbdf
As that plugin ([1]) is the mainstream one for sbt in IntelliJ IDEA.
Recommend the latter IDE use for this Scala project. Reformat the
build.sbt file accordingly, to start with. IntelliJ so far has been the
most stable and reproducible development environment for Scala with sbt.
[1] https://plugins.jetbrains.com/plugin/1347-scala
Change-Id: Ib1ca9bc7cac4dca5b7da114ea3f3068a522bccd6
- Add a / prefix for every root directory entry.
- Regroup related entries closer together.
- Remove entries covered by more general ones.
- Make the scala/sbt comment style consistent.
Change-Id: I130ba17e401acc47a2ecb95a2c79bfcb06c27779
Document how to set log levels for sbt commands.
Add a logback.xml configuration file that sets Gatling's own log level.
Mention that file in the documentation, too.
Change-Id: I9b7726d776dd153f3717cb9bf206aa99eb20b6f1
Introduce examples of scenarios to show how to load test Gerrit
using Gatling.
This initial examples only include tests over the git protocol, however
it is possible to expand the scenarios to mix different protocols (Git, SSH, Http).
Feature: Issue 10900
Change-Id: I00927b3b83f45ca852305780f5e67a4272d1ab22