honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/TESTING.asciidoc

681 lines
27 KiB
Plaintext
Raw Normal View History

Update TESTING.asciidoc title (#34401) Display `Testing` as h1
2018-10-15 01:54:18 -04:00
[[TestingFrameworkCheatsheet]]
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
= Testing
[partintro]
Document es.node.mode and add possible options to error message
2014-04-02 08:27:31 -04:00
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
Elasticsearch uses jUnit for testing, it also uses randomness in the
tests, that can be set using a seed, the following is a cheatsheet of
options for running the tests for ES.
== Creating packages
To create a distribution without running the tests, simply run the
following:
-----------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew assemble
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
-----------------------------
Update TESTING.asciidoc with platform specific instructions (#38802) This adds the instructions for building a platform-specific distribution.
2019-02-14 10:13:05 -05:00
To create a platform-specific build including the x-pack modules, use the
following depending on your operating system:
-----------------------------
./gradlew :distribution:archives:linux-tar:assemble --parallel
./gradlew :distribution:archives:darwin-tar:assemble --parallel
./gradlew :distribution:archives:windows-zip:assemble --parallel
-----------------------------
Add ability to launch bootstrapped ES using maven This adds the exec-maven-plugin that allows a developer to run: ``` mvn exec:exec ``` To launch the `Bootstrap` process similar to the way that a Java IDE would. All the logs go to logs/elasticsearch.log (or wherever configured)
2015-03-26 17:55:25 -04:00
=== Running Elasticsearch from a checkout
In order to run Elasticsearch from source without building a package, you can
Update TESTING.asciidoc (#19652)
2016-07-28 08:38:13 -04:00
run it using Gradle:
Add ability to launch bootstrapped ES using maven This adds the exec-maven-plugin that allows a developer to run: ``` mvn exec:exec ``` To launch the `Bootstrap` process similar to the way that a Java IDE would. All the logs go to logs/elasticsearch.log (or wherever configured)
2015-03-26 17:55:25 -04:00
-------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew run
Add ability to launch bootstrapped ES using maven This adds the exec-maven-plugin that allows a developer to run: ``` mvn exec:exec ``` To launch the `Bootstrap` process similar to the way that a Java IDE would. All the logs go to logs/elasticsearch.log (or wherever configured)
2015-03-26 17:55:25 -04:00
-------------------------------------
[Build] Add test admin when starting gradle run with trial license and also add more documentation around gradle run task. (#30671)
2018-05-18 08:11:11 -04:00
==== Launching and debugging from an IDE
If you want to run Elasticsearch from your IDE, the `./gradlew run` task
supports a remote debugging option:
---------------------------------------------------------------------------
./gradlew run --debug-jvm
---------------------------------------------------------------------------
Switch to debug with server=n (#48188) Before this change one needed to re-start debugging several times, as we launched multiple JVMs in debug mode. With this option the IDE has the option to re-launch and listen for connections again leading for to a more pleasant experience.
2019-10-21 08:06:03 -04:00
This will instruct all JVMs (including any that run cli tools such as creating the keyring or adding users)
[Docs] Fix testing docs regarding --debug-jvm (#48293) Remove extra whitespace and highlight the starting port number. Follows: #48188 (cherry picked from commit b84b7e13c888c9a4b110c436b4eec1ffd0aebd52)
2019-10-21 09:20:33 -04:00
to suspend and initiate a debug connection on port incrementing from `5005`.
Switch to debug with server=n (#48188) Before this change one needed to re-start debugging several times, as we launched multiple JVMs in debug mode. With this option the IDE has the option to re-launch and listen for connections again leading for to a more pleasant experience.
2019-10-21 08:06:03 -04:00
As such the IDE needs to be instructed to listen for connections on this port.
Since we might run multiple JVMs as part of configuring and starting the cluster it's
Detail the IDEs options for configuring the debug step (#48507) (cherry picked from commit 451d9cf06f1331ecfb6b4fa4acaed6fb43a1fcbb)
2019-10-25 10:26:22 -04:00
recommended to configure the IDE to initiate multiple listening attempts. In case of IntelliJ, this option
is called "Auto restart" and needs to be checked. In case of Eclipse, "Connection limit" setting
needs to be configured with a greater value (ie 10 or more).
Switch to debug with server=n (#48188) Before this change one needed to re-start debugging several times, as we launched multiple JVMs in debug mode. With this option the IDE has the option to re-launch and listen for connections again leading for to a more pleasant experience.
2019-10-21 08:06:03 -04:00
[Build] Add test admin when starting gradle run with trial license and also add more documentation around gradle run task. (#30671)
2018-05-18 08:11:11 -04:00
==== Distribution
By default a node is started with the zip distribution.
In order to start with a different distribution use the `-Drun.distribution` argument.
To for example start the open source distribution:
-------------------------------------
Simplify integ test distribution types (#37618) The integ tests currently use the raw zip project name as the distribution type. This commit simplifies this specification to be "default" or "oss". Whether zip or tar is used should be an internal implementation detail of the integ test setup, which can (in the future) be platform specific.
2019-01-21 15:37:17 -05:00
./gradlew run -Drun.distribution=oss
[Build] Add test admin when starting gradle run with trial license and also add more documentation around gradle run task. (#30671)
2018-05-18 08:11:11 -04:00
-------------------------------------
==== License type
By default a node is started with the `basic` license type.
In order to start with a different license type use the `-Drun.license_type` argument.
In order to start a node with a trial license execute the following command:
-------------------------------------
./gradlew run -Drun.license_type=trial
-------------------------------------
This enables security and other paid features and adds a superuser with the username: `elastic-admin` and
password: `elastic-password`.
==== Other useful arguments
In order to start a node with a different max heap space add: `-Dtests.heap.size=4G`
In order to disable annotations add: `-Dtests.asserts=false`
In order to set an Elasticsearch setting, provide a setting with the following prefix: `-Dtests.es.`
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
=== Test case filtering.
- `tests.class` is a class-filtering shell-like glob pattern,
- `tests.method` is a method-filtering glob pattern.
Run a single test case (variants)
----------------------------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.class=org.elasticsearch.package.ClassName
./gradlew test "-Dtests.class=*.ClassName"
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
----------------------------------------------------------
TESTING.asciidoc fix examples using forbidden annotation (#34515) Clean up examples not to use forbidden test annotation `@Nightly`. remove references to unused annotations
2018-10-23 05:36:42 -04:00
Run all tests in a package and its sub-packages
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
----------------------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test "-Dtests.class=org.elasticsearch.package.*"
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
----------------------------------------------------
TESTING.asciidoc fix examples using forbidden annotation (#34515) Clean up examples not to use forbidden test annotation `@Nightly`. remove references to unused annotations
2018-10-23 05:36:42 -04:00
Run any test methods that contain 'esi' (like: ...r*esi*ze...)
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
-------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test "-Dtests.method=*esi*"
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
-------------------------------
TESTING.asciidoc fix examples using forbidden annotation (#34515) Clean up examples not to use forbidden test annotation `@Nightly`. remove references to unused annotations
2018-10-23 05:36:42 -04:00
Run all tests that are waiting for a bugfix (disabled by default)
[TEST] Expose `tests.filter` for elasticsearch tests. `-Dtests.filter` allows to pass filter expressions to the elasticsearch tests. This allows to filter test annotaged with TestGroup annotations like @Slow, @Nightly, @Backwards, @Integration with a boolean expresssion like: * to run only backwards tests run: `mvn -Dtests.bwc.version=X.Y.Z -Dtests.filter="@backwards"` * to run all integration tests but skip slow tests run: `mvn -Dtests.filter="@integration and not @slow" * to take defaults into account ie run all test as well as backwards: `mvn -Dtests.filter="default and @backwards" This feature is a more powerful alternative to flags like `-Dtests.nighly=true|false` etc. Closes #6703
2014-07-03 04:52:29 -04:00
------------------------------------------------
TESTING.asciidoc fix examples using forbidden annotation (#34515) Clean up examples not to use forbidden test annotation `@Nightly`. remove references to unused annotations
2018-10-23 05:36:42 -04:00
./gradlew test -Dtests.filter=@awaitsfix
[TEST] Expose `tests.filter` for elasticsearch tests. `-Dtests.filter` allows to pass filter expressions to the elasticsearch tests. This allows to filter test annotaged with TestGroup annotations like @Slow, @Nightly, @Backwards, @Integration with a boolean expresssion like: * to run only backwards tests run: `mvn -Dtests.bwc.version=X.Y.Z -Dtests.filter="@backwards"` * to run all integration tests but skip slow tests run: `mvn -Dtests.filter="@integration and not @slow" * to take defaults into account ie run all test as well as backwards: `mvn -Dtests.filter="default and @backwards" This feature is a more powerful alternative to flags like `-Dtests.nighly=true|false` etc. Closes #6703
2014-07-03 04:52:29 -04:00
------------------------------------------------
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
=== Seed and repetitions.
Run with a given seed (seed is a hex-encoded long).
------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.seed=DEADBEEF
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
------------------------------
=== Repeats _all_ tests of ClassName N times.
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
Every test repetition will have a different method seed
The seed format is suite:method, clarified it in the docs.
2014-02-20 08:46:59 -05:00
(derived from a single random master seed).
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
--------------------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.iters=N -Dtests.class=*.ClassName
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
--------------------------------------------------
=== Repeats _all_ tests of ClassName N times.
The seed format is suite:method, clarified it in the docs.
2014-02-20 08:46:59 -05:00
Every test repetition will have exactly the same master (0xdead) and
method-level (0xbeef) seed.
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
------------------------------------------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.iters=N -Dtests.class=*.ClassName -Dtests.seed=DEAD:BEEF
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
------------------------------------------------------------------------
=== Repeats a given test N times
(note the filters - individual test repetitions are given suffixes,
ie: testFoo[0], testFoo[1], etc... so using testmethod or tests.method
ending in a glob is necessary to ensure iterations are run).
-------------------------------------------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.iters=N -Dtests.class=*.ClassName -Dtests.method=mytest*
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
-------------------------------------------------------------------------
Repeats N times but skips any tests after the first failure or M initial failures.
-------------------------------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.iters=N -Dtests.failfast=true -Dtestcase=...
./gradlew test -Dtests.iters=N -Dtests.maxfailures=M -Dtestcase=...
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
-------------------------------------------------------------
=== Test groups.
Test groups can be enabled or disabled (true/false).
Default value provided below in [brackets].
------------------------------------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.awaitsfix=[false] - known issue (@AwaitsFix)
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
------------------------------------------------------------------
=== Load balancing and caches.
Update TESTING.asciidoc for new :qa:os test style (#48023) * Update testing document for new packaging tests The TESTING.asciidoc document had gotten out of date due to some new and wonderful changes in our vagrant testing code. I've removed all of the instructions that no longer work, and added working examples and descriptions in their place.
2019-10-16 16:24:50 -04:00
By default the tests run on multiple processes using all the available cores on all
The default of tests.jvms should not be capped (#35259) Default to the number of physical cores across all sockets instead.
2018-11-19 07:01:32 -05:00
available CPUs. Not including hyper-threading.
If you want to explicitly specify the number of JVMs you can do so on the command
[doc] Information on JVM fork count I spent 20 minutes reading gradle docs to figure out how to do this. No one else should have to do that. Also, some of the documentation was out of date.
2015-10-08 15:16:47 -04:00
line:
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
----------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.jvms=8
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
----------------------------
[doc] Information on JVM fork count I spent 20 minutes reading gradle docs to figure out how to do this. No one else should have to do that. Also, some of the documentation was out of date.
2015-10-08 15:16:47 -04:00
Or in `~/.gradle/gradle.properties`:
----------------------------
systemProp.tests.jvms=8
----------------------------
Its difficult to pick the "right" number here. Hypercores don't count for CPU
intensive tests and you should leave some slack for JVM-interal threads like
the garbage collector. And you have to have enough RAM to handle each JVM.
Minor cleanups.
2014-02-25 06:38:22 -05:00
[TEST] Allow to disable randomization of shards and replicas via system property Needed for REST backwards compatibility tests, since we need to run older tests with the latest runner, which randomizes shards and replicas, but the tests rely on defaults (5,1). Done in a generic way based on compatibility versions e.g. `-Dtests.compatibility=1.0.0` allows to run tests in a special manner that is compatibile with 1.0.0 version. Also moved back randomIndexTemplate to ElasticsearchIntegrationTest (from ImmutableCluster) where all the randomized aspects should be. Closes #5897
2014-04-22 05:36:53 -04:00
=== Test compatibility.
It is possible to provide a version that allows to adapt the tests behaviour
to older features or bugs that have been changed or fixed in the meantime.
-----------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.compatibility=1.0.0
[TEST] Allow to disable randomization of shards and replicas via system property Needed for REST backwards compatibility tests, since we need to run older tests with the latest runner, which randomizes shards and replicas, but the tests rely on defaults (5,1). Done in a generic way based on compatibility versions e.g. `-Dtests.compatibility=1.0.0` allows to run tests in a special manner that is compatibile with 1.0.0 version. Also moved back randomIndexTemplate to ElasticsearchIntegrationTest (from ImmutableCluster) where all the randomized aspects should be. Closes #5897
2014-04-22 05:36:53 -04:00
-----------------------------------------
Minor cleanups.
2014-02-25 06:38:22 -05:00
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
=== Miscellaneous.
Run all tests without stopping on errors (inspect log files).
-----------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.haltonfailure=false
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
-----------------------------------------
Run more verbose output (slave JVM parameters, etc.).
----------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -verbose
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
----------------------
Minor cleanups.
2014-02-25 06:38:22 -05:00
Change the default suite timeout to 5 seconds for all
tests (note the exclamation mark).
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
---------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.timeoutSuite=5000! ...
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
---------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
Change the logging level of ES (not Gradle)
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
--------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.es.logger.level=DEBUG
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
--------------------------------
Print all the logging output from the test runs to the commandline
even if tests are passing.
------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.output=always
Add TESTING document describing test settings
2013-09-13 13:50:56 -04:00
------------------------------
added REST test suites runner The REST layer can now be tested through tests that are shared between all the elasticsearch official clients. The tests are based on REST specification that can be found on the elasticsearch-rest-api-spec project and consist of YAML files that describe the operations to be executed and the obtained results that need to be tested. REST tests can be executed through the ElasticsearchRestTests class, which relies on the rest-spec git submodule that contains the rest spec and tests pulled from the elasticsearch-rest-spec-api project. The rest-spec submodule gets automatically initialized and updated through maven (generate-test-resources phase). The REST runner and the needed classes are distributed within the test artifact. The following are the options supported by the REST tests runner: - tests.rest[true|false|host:port]: determines whether the REST tests need to be run and if so whether to rely on an external cluster (providing host and port) or fire a test cluster (default) - tests.rest.suite: comma separated paths of the test suites to be run (by default loaded from /rest-spec/test classpath). it is possible to run only a subset of the tests providing a sub-folder or even a single yaml file (the default /rest-spec/test prefix is optional when files are loaded from classpath) e.g. -Dtests.rest.suite=index,get,create/10_with_id - tests.rest.spec: REST spec path (default /rest-spec/api from classpath) - tests.iters: runs multiple iterations - tests.seed: seed to base the random behaviours on - tests.appendseed[true|false]: enables adding the seed to each test section's description (default false) - tests.cluster_seed: seed used to create the test cluster (if enabled) Closes #4469
2013-12-07 09:41:51 -05:00
Testing doc: describe -Dtests.heap.size and -Dtests.jvm.argline
2014-08-21 07:11:49 -04:00
Configure the heap size.
------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.heap.size=512m
Testing doc: describe -Dtests.heap.size and -Dtests.jvm.argline
2014-08-21 07:11:49 -04:00
------------------------------
Pass arbitrary jvm arguments.
------------------------------
Upgrade to randomizedtesting 2.2.0 Closes #14342
2015-10-28 15:28:30 -04:00
# specify heap dump path
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.jvm.argline="-XX:HeapDumpPath=/path/to/heapdumps"
Upgrade to randomizedtesting 2.2.0 Closes #14342
2015-10-28 15:28:30 -04:00
# enable gc logging
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.jvm.argline="-verbose:gc"
Upgrade to randomizedtesting 2.2.0 Closes #14342
2015-10-28 15:28:30 -04:00
# enable security debugging
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew test -Dtests.jvm.argline="-Djava.security.debug=access,failure"
Testing doc: describe -Dtests.heap.size and -Dtests.jvm.argline
2014-08-21 07:11:49 -04:00
------------------------------
Switch build system to Gradle See #13930
2015-10-29 14:40:19 -04:00
== Running verification tasks
Fix coverage analysis. Two versions of jacoco were being used and creating jar hell
2015-08-03 23:08:18 -04:00
Switch build system to Gradle See #13930
2015-10-29 14:40:19 -04:00
To run all verification tasks, including static checks, unit tests, and integration tests:
Fix coverage analysis. Two versions of jacoco were being used and creating jar hell
2015-08-03 23:08:18 -04:00
---------------------------------------------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew check
Fix coverage analysis. Two versions of jacoco were being used and creating jar hell
2015-08-03 23:08:18 -04:00
---------------------------------------------------------------------------
Switch build system to Gradle See #13930
2015-10-29 14:40:19 -04:00
Note that this will also run the unit tests and precommit tasks first. If you want to just
run the integration tests (because you are debugging them):
Fix coverage analysis. Two versions of jacoco were being used and creating jar hell
2015-08-03 23:08:18 -04:00
---------------------------------------------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew integTest
Switch build system to Gradle See #13930
2015-10-29 14:40:19 -04:00
---------------------------------------------------------------------------
If you want to just run the precommit checks:
---------------------------------------------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew precommit
Fix coverage analysis. Two versions of jacoco were being used and creating jar hell
2015-08-03 23:08:18 -04:00
---------------------------------------------------------------------------
Replace fixtures with docker-compose (#35651) Creates a new plugin to manage docker-compose based test fixtures. Convert the smb-fixture as a first example.
2018-11-29 02:43:16 -05:00
Some of these checks will require `docker-compose` installed for bringing up
test fixtures. If it's not present those checks will be skipped automatically.
added REST test suites runner The REST layer can now be tested through tests that are shared between all the elasticsearch official clients. The tests are based on REST specification that can be found on the elasticsearch-rest-api-spec project and consist of YAML files that describe the operations to be executed and the obtained results that need to be tested. REST tests can be executed through the ElasticsearchRestTests class, which relies on the rest-spec git submodule that contains the rest spec and tests pulled from the elasticsearch-rest-spec-api project. The rest-spec submodule gets automatically initialized and updated through maven (generate-test-resources phase). The REST runner and the needed classes are distributed within the test artifact. The following are the options supported by the REST tests runner: - tests.rest[true|false|host:port]: determines whether the REST tests need to be run and if so whether to rely on an external cluster (providing host and port) or fire a test cluster (default) - tests.rest.suite: comma separated paths of the test suites to be run (by default loaded from /rest-spec/test classpath). it is possible to run only a subset of the tests providing a sub-folder or even a single yaml file (the default /rest-spec/test prefix is optional when files are loaded from classpath) e.g. -Dtests.rest.suite=index,get,create/10_with_id - tests.rest.spec: REST spec path (default /rest-spec/api from classpath) - tests.iters: runs multiple iterations - tests.seed: seed to base the random behaviours on - tests.appendseed[true|false]: enables adding the seed to each test section's description (default false) - tests.cluster_seed: seed used to create the test cluster (if enabled) Closes #4469
2013-12-07 09:41:51 -05:00
== Testing the REST layer
The available integration tests make use of the java API to communicate with
the elasticsearch nodes, using the internal binary transport (port 9300 by
default).
The REST layer is tested through specific tests that are shared between all
removed rest-spec submodule and prepared project for same files added directly to the codebase (no submodule) within rest-api-spec (temporarily disabled FileUtilsTests & REST tests as there's temporarily no rest-spec dir) Relates to #4540 #4376
2013-12-27 14:36:12 -05:00
the elasticsearch official clients and consist of YAML files that describe the
operations to be executed and the obtained results that need to be tested.
added REST test suites runner The REST layer can now be tested through tests that are shared between all the elasticsearch official clients. The tests are based on REST specification that can be found on the elasticsearch-rest-api-spec project and consist of YAML files that describe the operations to be executed and the obtained results that need to be tested. REST tests can be executed through the ElasticsearchRestTests class, which relies on the rest-spec git submodule that contains the rest spec and tests pulled from the elasticsearch-rest-spec-api project. The rest-spec submodule gets automatically initialized and updated through maven (generate-test-resources phase). The REST runner and the needed classes are distributed within the test artifact. The following are the options supported by the REST tests runner: - tests.rest[true|false|host:port]: determines whether the REST tests need to be run and if so whether to rely on an external cluster (providing host and port) or fire a test cluster (default) - tests.rest.suite: comma separated paths of the test suites to be run (by default loaded from /rest-spec/test classpath). it is possible to run only a subset of the tests providing a sub-folder or even a single yaml file (the default /rest-spec/test prefix is optional when files are loaded from classpath) e.g. -Dtests.rest.suite=index,get,create/10_with_id - tests.rest.spec: REST spec path (default /rest-spec/api from classpath) - tests.iters: runs multiple iterations - tests.seed: seed to base the random behaviours on - tests.appendseed[true|false]: enables adding the seed to each test section's description (default false) - tests.cluster_seed: seed used to create the test cluster (if enabled) Closes #4469
2013-12-07 09:41:51 -05:00
Highlight the "hidden" REST API test suite (#28381)
2018-02-09 18:05:19 -05:00
The YAML files support various operators defined in the link:/rest-api-spec/src/main/resources/rest-api-spec/test/README.asciidoc[rest-api-spec] and adhere to the link:/rest-api-spec/README.markdown[Elasticsearch REST API JSON specification]
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
The REST tests are run automatically when executing the "./gradlew check" command. To run only the
Extended TESTING.asciidoc with an example of running just the REST tests from maven
2013-12-18 04:55:57 -05:00
REST tests use the following command:
---------------------------------------------------------------------------
Update Gradle Testing Docs (#28970) Attempting to run the REST tests, I noticed the testing instructions in the `TESTING.asciidoc` were outdated, so I fixed the paths. Steps I took to test: * Ran `./gradlew :distribution:packages:rpm:assemble` and make sure RPM is created in `./distribution/packages/rpm/build/distributions/` * Ran testing commands and verified the REST tests ran.
2018-03-09 14:54:59 -05:00
./gradlew :distribution:archives:integ-test-zip:integTest \
Add quotes to prevent shell globbing in TESTING.asciidoc
2016-08-09 11:02:27 -04:00
-Dtests.class="org.elasticsearch.test.rest.*Yaml*IT"
Fix REST test command line instructions Closes #15154
2015-12-01 11:33:46 -05:00
---------------------------------------------------------------------------
A specific test case can be run with
---------------------------------------------------------------------------
Update Gradle Testing Docs (#28970) Attempting to run the REST tests, I noticed the testing instructions in the `TESTING.asciidoc` were outdated, so I fixed the paths. Steps I took to test: * Ran `./gradlew :distribution:packages:rpm:assemble` and make sure RPM is created in `./distribution/packages/rpm/build/distributions/` * Ran testing commands and verified the REST tests ran.
2018-03-09 14:54:59 -05:00
./gradlew :distribution:archives:integ-test-zip:integTest \
Add quotes to prevent shell globbing in TESTING.asciidoc
2016-08-09 11:02:27 -04:00
-Dtests.class="org.elasticsearch.test.rest.*Yaml*IT" \
Fix REST test command line instructions Closes #15154
2015-12-01 11:33:46 -05:00
-Dtests.method="test {p0=cat.shards/10_basic/Help}"
Extended TESTING.asciidoc with an example of running just the REST tests from maven
2013-12-18 04:55:57 -05:00
---------------------------------------------------------------------------
Fix REST test documentation To run the tests we have to use now `*Yaml*IT` instead of `RestIT`: ```sh gradle :distribution:integ-test-zip:integTest -Dtests.class=org.elasticsearch.test.rest.*Yaml*IT ```
2016-08-03 07:50:24 -04:00
`*Yaml*IT` are the executable test classes that runs all the
re-enabled FileUtilsTests and REST tests as rest-api-spec has been added back fixed rest-api-spec paths in TESTING docs Relates to #4540 & #4376
2013-12-27 14:43:16 -05:00
yaml suites available within the `rest-api-spec` folder.
added REST test suites runner The REST layer can now be tested through tests that are shared between all the elasticsearch official clients. The tests are based on REST specification that can be found on the elasticsearch-rest-api-spec project and consist of YAML files that describe the operations to be executed and the obtained results that need to be tested. REST tests can be executed through the ElasticsearchRestTests class, which relies on the rest-spec git submodule that contains the rest spec and tests pulled from the elasticsearch-rest-spec-api project. The rest-spec submodule gets automatically initialized and updated through maven (generate-test-resources phase). The REST runner and the needed classes are distributed within the test artifact. The following are the options supported by the REST tests runner: - tests.rest[true|false|host:port]: determines whether the REST tests need to be run and if so whether to rely on an external cluster (providing host and port) or fire a test cluster (default) - tests.rest.suite: comma separated paths of the test suites to be run (by default loaded from /rest-spec/test classpath). it is possible to run only a subset of the tests providing a sub-folder or even a single yaml file (the default /rest-spec/test prefix is optional when files are loaded from classpath) e.g. -Dtests.rest.suite=index,get,create/10_with_id - tests.rest.spec: REST spec path (default /rest-spec/api from classpath) - tests.iters: runs multiple iterations - tests.seed: seed to base the random behaviours on - tests.appendseed[true|false]: enables adding the seed to each test section's description (default false) - tests.cluster_seed: seed used to create the test cluster (if enabled) Closes #4469
2013-12-07 09:41:51 -05:00
[TEST] Replaced RestTestSuiteRunner with parametrized test that uses RandomizedRunner directly ElasticsearchRestTests extends now ElasticsearchIntegrationTest and makes use of our ordinary test infrastructure, in particular all randomized aspects now come for free instead of having to maintain a separate (custom) tests runner We previously parsed only the tests that needed to be run given the version of the cluster the tests are running against. This doesn't happen anymore as it didn't buy much and it would be harder to support as the tests get now parsed before the test cluster gets started. Thus all the tests are now parsed regardless of their skip sections, afterwards the ones that don't need to be run will be skipped through assume directives. Fixed REST tests that rely on a specific number of shards as this change introduces also random number of shards and replicas (through randomIndexTemplate) Closes #5654
2014-03-10 08:48:17 -04:00
The REST tests support all the options provided by the randomized runner, plus the following:
added REST test suites runner The REST layer can now be tested through tests that are shared between all the elasticsearch official clients. The tests are based on REST specification that can be found on the elasticsearch-rest-api-spec project and consist of YAML files that describe the operations to be executed and the obtained results that need to be tested. REST tests can be executed through the ElasticsearchRestTests class, which relies on the rest-spec git submodule that contains the rest spec and tests pulled from the elasticsearch-rest-spec-api project. The rest-spec submodule gets automatically initialized and updated through maven (generate-test-resources phase). The REST runner and the needed classes are distributed within the test artifact. The following are the options supported by the REST tests runner: - tests.rest[true|false|host:port]: determines whether the REST tests need to be run and if so whether to rely on an external cluster (providing host and port) or fire a test cluster (default) - tests.rest.suite: comma separated paths of the test suites to be run (by default loaded from /rest-spec/test classpath). it is possible to run only a subset of the tests providing a sub-folder or even a single yaml file (the default /rest-spec/test prefix is optional when files are loaded from classpath) e.g. -Dtests.rest.suite=index,get,create/10_with_id - tests.rest.spec: REST spec path (default /rest-spec/api from classpath) - tests.iters: runs multiple iterations - tests.seed: seed to base the random behaviours on - tests.appendseed[true|false]: enables adding the seed to each test section's description (default false) - tests.cluster_seed: seed used to create the test cluster (if enabled) Closes #4469
2013-12-07 09:41:51 -05:00
[TEST] Replaced RestTestSuiteRunner with parametrized test that uses RandomizedRunner directly ElasticsearchRestTests extends now ElasticsearchIntegrationTest and makes use of our ordinary test infrastructure, in particular all randomized aspects now come for free instead of having to maintain a separate (custom) tests runner We previously parsed only the tests that needed to be run given the version of the cluster the tests are running against. This doesn't happen anymore as it didn't buy much and it would be harder to support as the tests get now parsed before the test cluster gets started. Thus all the tests are now parsed regardless of their skip sections, afterwards the ones that don't need to be run will be skipped through assume directives. Fixed REST tests that rely on a specific number of shards as this change introduces also random number of shards and replicas (through randomIndexTemplate) Closes #5654
2014-03-10 08:48:17 -04:00
* `tests.rest[true|false]`: determines whether the REST tests need to be run (default) or not.
added REST test suites runner The REST layer can now be tested through tests that are shared between all the elasticsearch official clients. The tests are based on REST specification that can be found on the elasticsearch-rest-api-spec project and consist of YAML files that describe the operations to be executed and the obtained results that need to be tested. REST tests can be executed through the ElasticsearchRestTests class, which relies on the rest-spec git submodule that contains the rest spec and tests pulled from the elasticsearch-rest-spec-api project. The rest-spec submodule gets automatically initialized and updated through maven (generate-test-resources phase). The REST runner and the needed classes are distributed within the test artifact. The following are the options supported by the REST tests runner: - tests.rest[true|false|host:port]: determines whether the REST tests need to be run and if so whether to rely on an external cluster (providing host and port) or fire a test cluster (default) - tests.rest.suite: comma separated paths of the test suites to be run (by default loaded from /rest-spec/test classpath). it is possible to run only a subset of the tests providing a sub-folder or even a single yaml file (the default /rest-spec/test prefix is optional when files are loaded from classpath) e.g. -Dtests.rest.suite=index,get,create/10_with_id - tests.rest.spec: REST spec path (default /rest-spec/api from classpath) - tests.iters: runs multiple iterations - tests.seed: seed to base the random behaviours on - tests.appendseed[true|false]: enables adding the seed to each test section's description (default false) - tests.cluster_seed: seed used to create the test cluster (if enabled) Closes #4469
2013-12-07 09:41:51 -05:00
* `tests.rest.suite`: comma separated paths of the test suites to be run
re-enabled FileUtilsTests and REST tests as rest-api-spec has been added back fixed rest-api-spec paths in TESTING docs Relates to #4540 & #4376
2013-12-27 14:43:16 -05:00
(by default loaded from /rest-api-spec/test). It is possible to run only a subset
added REST test suites runner The REST layer can now be tested through tests that are shared between all the elasticsearch official clients. The tests are based on REST specification that can be found on the elasticsearch-rest-api-spec project and consist of YAML files that describe the operations to be executed and the obtained results that need to be tested. REST tests can be executed through the ElasticsearchRestTests class, which relies on the rest-spec git submodule that contains the rest spec and tests pulled from the elasticsearch-rest-spec-api project. The rest-spec submodule gets automatically initialized and updated through maven (generate-test-resources phase). The REST runner and the needed classes are distributed within the test artifact. The following are the options supported by the REST tests runner: - tests.rest[true|false|host:port]: determines whether the REST tests need to be run and if so whether to rely on an external cluster (providing host and port) or fire a test cluster (default) - tests.rest.suite: comma separated paths of the test suites to be run (by default loaded from /rest-spec/test classpath). it is possible to run only a subset of the tests providing a sub-folder or even a single yaml file (the default /rest-spec/test prefix is optional when files are loaded from classpath) e.g. -Dtests.rest.suite=index,get,create/10_with_id - tests.rest.spec: REST spec path (default /rest-spec/api from classpath) - tests.iters: runs multiple iterations - tests.seed: seed to base the random behaviours on - tests.appendseed[true|false]: enables adding the seed to each test section's description (default false) - tests.cluster_seed: seed used to create the test cluster (if enabled) Closes #4469
2013-12-07 09:41:51 -05:00
of the tests providing a sub-folder or even a single yaml file (the default
re-enabled FileUtilsTests and REST tests as rest-api-spec has been added back fixed rest-api-spec paths in TESTING docs Relates to #4540 & #4376
2013-12-27 14:43:16 -05:00
/rest-api-spec/test prefix is optional when files are loaded from classpath)
added REST test suites runner The REST layer can now be tested through tests that are shared between all the elasticsearch official clients. The tests are based on REST specification that can be found on the elasticsearch-rest-api-spec project and consist of YAML files that describe the operations to be executed and the obtained results that need to be tested. REST tests can be executed through the ElasticsearchRestTests class, which relies on the rest-spec git submodule that contains the rest spec and tests pulled from the elasticsearch-rest-spec-api project. The rest-spec submodule gets automatically initialized and updated through maven (generate-test-resources phase). The REST runner and the needed classes are distributed within the test artifact. The following are the options supported by the REST tests runner: - tests.rest[true|false|host:port]: determines whether the REST tests need to be run and if so whether to rely on an external cluster (providing host and port) or fire a test cluster (default) - tests.rest.suite: comma separated paths of the test suites to be run (by default loaded from /rest-spec/test classpath). it is possible to run only a subset of the tests providing a sub-folder or even a single yaml file (the default /rest-spec/test prefix is optional when files are loaded from classpath) e.g. -Dtests.rest.suite=index,get,create/10_with_id - tests.rest.spec: REST spec path (default /rest-spec/api from classpath) - tests.iters: runs multiple iterations - tests.seed: seed to base the random behaviours on - tests.appendseed[true|false]: enables adding the seed to each test section's description (default false) - tests.cluster_seed: seed used to create the test cluster (if enabled) Closes #4469
2013-12-07 09:41:51 -05:00
e.g. -Dtests.rest.suite=index,get,create/10_with_id
[TEST] Added blacklist to be able to skip specific REST tests The blacklist can be provided through -Dtests.rest.blacklist and supports a comma separated list of globs e.g. -Dtests.rest.blacklist=get/10_basic/*,index/*/* Also added some missing docs and made it clearer that the suite/test descriptions effectively contains their (relative) path (api/yaml_file/test section) Closes #5881
2014-04-19 05:13:51 -04:00
* `tests.rest.blacklist`: comma separated globs that identify tests that are
blacklisted and need to be skipped
e.g. -Dtests.rest.blacklist=index/*/Index document,get/10_basic/*
[TEST] Replaced RestTestSuiteRunner with parametrized test that uses RandomizedRunner directly ElasticsearchRestTests extends now ElasticsearchIntegrationTest and makes use of our ordinary test infrastructure, in particular all randomized aspects now come for free instead of having to maintain a separate (custom) tests runner We previously parsed only the tests that needed to be run given the version of the cluster the tests are running against. This doesn't happen anymore as it didn't buy much and it would be harder to support as the tests get now parsed before the test cluster gets started. Thus all the tests are now parsed regardless of their skip sections, afterwards the ones that don't need to be run will be skipped through assume directives. Fixed REST tests that rely on a specific number of shards as this change introduces also random number of shards and replicas (through randomIndexTemplate) Closes #5654
2014-03-10 08:48:17 -04:00
Note that the REST tests, like all the integration tests, can be run against an external
cluster by specifying the `tests.cluster` property, which if present needs to contain a
comma separated list of nodes to connect to (e.g. localhost:9300). A transport client will
be created based on that and used for all the before|after test operations, and to extract
the http addresses of the nodes so that REST requests can be sent to them.
[TEST] Add basic Backwards Compatibility Tests This commit add a basic infrastructure as well as primitive tests to ensure version backwards compatibility between the current development trunk and an arbitrary previous version. The compatibility tests are simple unit tests derived from a base class that starts and manages nodes from a provided elasticsearch release package. Use the following commandline executes all backwards compatiblity tests in isolation: ``` mvn test -Dtests.bwc=true -Dtests.bwc.version=1.2.1 -Dtests.class=org.elasticsearch.bwcompat.* ``` These tests run basic checks like rolling upgrades and routing/searching/get etc. against the specified version. The version must be present in the `./backwards` folder as `./backwards/elasticsearch-x.y.z`
2014-05-14 11:52:02 -04:00
[test] packaging: add windows boxes (#30402) Adds windows server 2012r2 and 2016 vagrant boxes to packaging tests. They can only be used if IDs for their images are specified, which are passed to gradle and then to vagrant via env variables. Adds options to the project property `vagrant.boxes` to choose between linux and windows boxes. Bats tests are run only on linux boxes, and portable packaging tests run on all boxes. Platform tests are only run on linux boxes since they are not being maintained. For #26741
2018-05-16 19:42:08 -04:00
== Testing packaging
Standardization of packages structure and install The existing DEB/RPM packages have a lot of differences: they don't execute the same actions when installing or removing the package. They also don't declare exactly the same environment variables at the same place. At the end of the day the global behavior and configuration is *almost* the same but it's very difficult to maintain the scripts. This commits unifies the package behavior: - DEB/RPM use the same package scripts (pre installation, post installation etc) in order to execute exactly the same actions - Use of a unique environment vars file that declares everything needed by scripts (the goal is to delete vars declaration in init.d and systemd scripts, this will be done in another PR) - Variables like directory paths are centralized and replaced according to the target platform (using #10330) - Move /etc/rc.d/init.d to standard /etc/init.d (RPM only) - Add PID_DIR env var - Always set ES_USER, ES_GROUP,MAX_MAP_COUNT and MAX_OPEN_FILES in env vars file - Create log, data, work and plugins directories with DEB/RPM packaging system - Change to elastic.co domain in copyright and control files - Add Bats files to automate testing of DEB and RPM packages - Update TESTING.asciidoc More info on Bats here: https://github.com/sstephenson/bats
2015-04-14 10:22:37 -04:00
Update TESTING.asciidoc for new :qa:os test style (#48023) * Update testing document for new packaging tests The TESTING.asciidoc document had gotten out of date due to some new and wonderful changes in our vagrant testing code. I've removed all of the instructions that no longer work, and added working examples and descriptions in their place.
2019-10-16 16:24:50 -04:00
The packaging tests use Vagrant virtual machines or cloud instances to verify
that installing and running Elasticsearch distributions works correctly on
supported operating systems. These tests should really only be run on ephemeral
systems because they're destructive; that is, these tests install and remove
packages and freely modify system settings, so you will probably regret it if
you execute them on your development machine.
When you run a packaging test, Gradle will set up the target VM and mount your
repository directory in the VM. Once this is done, a Gradle task will issue a
Vagrant command to run a *nested* Gradle task on the VM. This nested Gradle
runs the actual "destructive" test classes.
Standardization of packages structure and install The existing DEB/RPM packages have a lot of differences: they don't execute the same actions when installing or removing the package. They also don't declare exactly the same environment variables at the same place. At the end of the day the global behavior and configuration is *almost* the same but it's very difficult to maintain the scripts. This commits unifies the package behavior: - DEB/RPM use the same package scripts (pre installation, post installation etc) in order to execute exactly the same actions - Use of a unique environment vars file that declares everything needed by scripts (the goal is to delete vars declaration in init.d and systemd scripts, this will be done in another PR) - Variables like directory paths are centralized and replaced according to the target platform (using #10330) - Move /etc/rc.d/init.d to standard /etc/init.d (RPM only) - Add PID_DIR env var - Always set ES_USER, ES_GROUP,MAX_MAP_COUNT and MAX_OPEN_FILES in env vars file - Create log, data, work and plugins directories with DEB/RPM packaging system - Change to elastic.co domain in copyright and control files - Add Bats files to automate testing of DEB and RPM packages - Update TESTING.asciidoc More info on Bats here: https://github.com/sstephenson/bats
2015-04-14 10:22:37 -04:00
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
. Install Virtual Box and Vagrant.
[DOCS] Fix list formatting in TESTING.asciidoc (#33889) Fix the steps listed in `Testing packaging` to ``` 1. step1 2. step2 -------------------------------------- vagrant plugin install vagrant-cachier -------------------------------------- 3. step3 ``` instead of ``` instead of: 1. step1 2. step2 -------------------------------------- vagrant plugin install vagrant-cachier -------------------------------------- 1. step3 ```
2018-09-20 16:14:56 -04:00
+
[test] packaging: add windows boxes (#30402) Adds windows server 2012r2 and 2016 vagrant boxes to packaging tests. They can only be used if IDs for their images are specified, which are passed to gradle and then to vagrant via env variables. Adds options to the project property `vagrant.boxes` to choose between linux and windows boxes. Bats tests are run only on linux boxes, and portable packaging tests run on all boxes. Platform tests are only run on linux boxes since they are not being maintained. For #26741
2018-05-16 19:42:08 -04:00
. (Optional) Install https://github.com/fgrehm/vagrant-cachier[vagrant-cachier] to squeeze
a bit more performance out of the process:
[DOCS] Fix list formatting in TESTING.asciidoc (#33889) Fix the steps listed in `Testing packaging` to ``` 1. step1 2. step2 -------------------------------------- vagrant plugin install vagrant-cachier -------------------------------------- 3. step3 ``` instead of ``` instead of: 1. step1 2. step2 -------------------------------------- vagrant plugin install vagrant-cachier -------------------------------------- 1. step3 ```
2018-09-20 16:14:56 -04:00
+
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
--------------------------------------
vagrant plugin install vagrant-cachier
--------------------------------------
[DOCS] Fix list formatting in TESTING.asciidoc (#33889) Fix the steps listed in `Testing packaging` to ``` 1. step1 2. step2 -------------------------------------- vagrant plugin install vagrant-cachier -------------------------------------- 3. step3 ``` instead of ``` instead of: 1. step1 2. step2 -------------------------------------- vagrant plugin install vagrant-cachier -------------------------------------- 1. step3 ```
2018-09-20 16:14:56 -04:00
+
Update TESTING.asciidoc for new :qa:os test style (#48023) * Update testing document for new packaging tests The TESTING.asciidoc document had gotten out of date due to some new and wonderful changes in our vagrant testing code. I've removed all of the instructions that no longer work, and added working examples and descriptions in their place.
2019-10-16 16:24:50 -04:00
. You can run all of the OS packaging tests with `./gradlew packagingTest`.
This task includes our legacy `bats` tests. To run only the OS tests that are
written in Java, run `.gradlew distroTest`, will cause Gradle to build the tar,
zip, and deb packages and all the plugins. It will then run the tests on every
available system. This will take a very long time.
[DOCS] Fix list formatting in TESTING.asciidoc (#33889) Fix the steps listed in `Testing packaging` to ``` 1. step1 2. step2 -------------------------------------- vagrant plugin install vagrant-cachier -------------------------------------- 3. step3 ``` instead of ``` instead of: 1. step1 2. step2 -------------------------------------- vagrant plugin install vagrant-cachier -------------------------------------- 1. step3 ```
2018-09-20 16:14:56 -04:00
+
Update TESTING.asciidoc for new :qa:os test style (#48023) * Update testing document for new packaging tests The TESTING.asciidoc document had gotten out of date due to some new and wonderful changes in our vagrant testing code. I've removed all of the instructions that no longer work, and added working examples and descriptions in their place.
2019-10-16 16:24:50 -04:00
Fortunately, the various systems under test have their own Gradle tasks under
`qa/os`. To find out what packaging combinations can be tested on a system, run
the `tasks` task. For example:
[DOCS] Fix list formatting in TESTING.asciidoc (#33889) Fix the steps listed in `Testing packaging` to ``` 1. step1 2. step2 -------------------------------------- vagrant plugin install vagrant-cachier -------------------------------------- 3. step3 ``` instead of ``` instead of: 1. step1 2. step2 -------------------------------------- vagrant plugin install vagrant-cachier -------------------------------------- 1. step3 ```
2018-09-20 16:14:56 -04:00
+
Update TESTING.asciidoc for new :qa:os test style (#48023) * Update testing document for new packaging tests The TESTING.asciidoc document had gotten out of date due to some new and wonderful changes in our vagrant testing code. I've removed all of the instructions that no longer work, and added working examples and descriptions in their place.
2019-10-16 16:24:50 -04:00
----------------------------------
./gradlew :qa:os:ubuntu-1804:tasks
----------------------------------
[DOCS] Fix list formatting in TESTING.asciidoc (#33889) Fix the steps listed in `Testing packaging` to ``` 1. step1 2. step2 -------------------------------------- vagrant plugin install vagrant-cachier -------------------------------------- 3. step3 ``` instead of ``` instead of: 1. step1 2. step2 -------------------------------------- vagrant plugin install vagrant-cachier -------------------------------------- 1. step3 ```
2018-09-20 16:14:56 -04:00
+
Update TESTING.asciidoc for new :qa:os test style (#48023) * Update testing document for new packaging tests The TESTING.asciidoc document had gotten out of date due to some new and wonderful changes in our vagrant testing code. I've removed all of the instructions that no longer work, and added working examples and descriptions in their place.
2019-10-16 16:24:50 -04:00
If you want a quick test of the tarball and RPM packagings for Centos 7, you
would run:
+
-------------------------------------------------------------------------------------------------
./gradlew :qa:os:centos-7:distroTest.default-rpm :qa:os:centos-7:distroTest.default-linux-archive
-------------------------------------------------------------------------------------------------
Note that if you interrupt Gradle in the middle of running these tasks, any boxes started
will remain running and you'll have to stop them manually with `./gradlew --stop` or
[test] packaging: add windows boxes (#30402) Adds windows server 2012r2 and 2016 vagrant boxes to packaging tests. They can only be used if IDs for their images are specified, which are passed to gradle and then to vagrant via env variables. Adds options to the project property `vagrant.boxes` to choose between linux and windows boxes. Bats tests are run only on linux boxes, and portable packaging tests run on all boxes. Platform tests are only run on linux boxes since they are not being maintained. For #26741
2018-05-16 19:42:08 -04:00
`vagrant halt`.
[doc] fix asciidoc format
2015-08-17 11:45:18 -04:00
[test] Gradle-ify vagrant tests This gets the tar and tar_plugins tests working in gradle. It does so by adding a subproject, qa/vagrant, which adds the following tasks: Verification ------------ checkPackages - Check the packages against a representative sample of the linux distributions we have in our Vagrantfile checkPackagesAllDistros - Check the packages against all the linux distributions we have in our Vagrantfile Package Verification -------------------- checkCentos6 - Run packaging tests against centos-6 checkCentos7 - Run packaging tests against centos-7 checkDebian8 - Run packaging tests against debian-8 checkFedora22 - Run packaging tests against fedora-22 checkOel7 - Run packaging tests against oel-7 checkOpensuse13 - Run packaging tests against opensuse-13 checkSles12 - Run packaging tests against sles-12 checkUbuntu1204 - Run packaging tests against ubuntu-1204 checkUbuntu1404 - Run packaging tests against ubuntu-1404 checkUbuntu1504 - Run packaging tests against ubuntu-1504 Vagrant ------- smokeTestCentos6 - Smoke test the centos-6 VM smokeTestCentos7 - Smoke test the centos-7 VM smokeTestDebian8 - Smoke test the debian-8 VM smokeTestFedora22 - Smoke test the fedora-22 VM smokeTestOel7 - Smoke test the oel-7 VM smokeTestOpensuse13 - Smoke test the opensuse-13 VM smokeTestSles12 - Smoke test the sles-12 VM smokeTestUbuntu1204 - Smoke test the ubuntu-1204 VM smokeTestUbuntu1404 - Smoke test the ubuntu-1404 VM smokeTestUbuntu1504 - Smoke test the ubuntu-1504 VM vagrantHaltCentos6 - Shutdown the vagrant VM running centos-6 vagrantHaltCentos7 - Shutdown the vagrant VM running centos-7 vagrantHaltDebian8 - Shutdown the vagrant VM running debian-8 vagrantHaltFedora22 - Shutdown the vagrant VM running fedora-22 vagrantHaltOel7 - Shutdown the vagrant VM running oel-7 vagrantHaltOpensuse13 - Shutdown the vagrant VM running opensuse-13 vagrantHaltSles12 - Shutdown the vagrant VM running sles-12 vagrantHaltUbuntu1204 - Shutdown the vagrant VM running ubuntu-1204 vagrantHaltUbuntu1404 - Shutdown the vagrant VM running ubuntu-1404 vagrantHaltUbuntu1504 - Shutdown the vagrant VM running ubuntu-1504 vagrantSmokeTest - Smoke test some representative distros from the Vagrantfile vagrantSmokeTestAllDistros - Smoke test all distros from the Vagrantfile vagrantUpCentos6 - Startup a vagrant VM running centos-6 vagrantUpCentos7 - Startup a vagrant VM running centos-7 vagrantUpDebian8 - Startup a vagrant VM running debian-8 vagrantUpFedora22 - Startup a vagrant VM running fedora-22 vagrantUpOel7 - Startup a vagrant VM running oel-7 vagrantUpOpensuse13 - Startup a vagrant VM running opensuse-13 vagrantUpSles12 - Startup a vagrant VM running sles-12 vagrantUpUbuntu1204 - Startup a vagrant VM running ubuntu-1204 vagrantUpUbuntu1404 - Startup a vagrant VM running ubuntu-1404 vagrantUpUbuntu1504 - Startup a vagrant VM running ubuntu-1504 It does not make the "check" task depend on "checkPackages" so running the vagrant tests is still optional. They are slow and depend on vagrant and virtualbox. The Package Verification tasks are useful for testing individual distros. The Vagrant tasks are listed in `gradle tasks` primarily for discoverability.
2015-11-02 12:40:47 -05:00
All the regular vagrant commands should just work so you can get a shell in a
VM running trusty by running
Drop support for Ubuntu 14.04 (#40709) With the 7.0.0 release, we are dropping support for Ubuntu 14.04. This commit removes this OS from our testing infrastructure.
2019-04-02 08:51:11 -04:00
`vagrant up ubuntu-1604 --provider virtualbox && vagrant ssh ubuntu-1604`.
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
[test] packaging: add windows boxes (#30402) Adds windows server 2012r2 and 2016 vagrant boxes to packaging tests. They can only be used if IDs for their images are specified, which are passed to gradle and then to vagrant via env variables. Adds options to the project property `vagrant.boxes` to choose between linux and windows boxes. Bats tests are run only on linux boxes, and portable packaging tests run on all boxes. Platform tests are only run on linux boxes since they are not being maintained. For #26741
2018-05-16 19:42:08 -04:00
These are the linux flavors supported, all of which we provide images for
[doc] fix asciidoc format
2015-08-17 11:45:18 -04:00
Add Ubuntu-16.04 to Vagrant VMs (#20425)
2016-09-12 11:58:32 -04:00
* ubuntu-1604 aka xenial
Add Ubuntu 18.04 to packaging tests (#34139) We intend to start supporting Ubuntu 18.04 with the 6.5.0 release. This commit adds Ubuntu 18.04 to the packaging tests.
2018-09-28 17:33:29 -04:00
* ubuntu-1804 aka bionic beaver
Tests: Add Debian 9 (Stretch) to the packaging tests Debian 9 aka Stretch is the current stable[1]. Add Debian-9 to the packaging tests. [1] https://wiki.debian.org/DebianStretch Relates #25494
2017-07-03 04:02:17 -04:00
* debian-8 aka jessie
* debian-9 aka stretch, the current debian stable distribution
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
* centos-6
* centos-7
Run packaging tests on RHEL 8 (#41662)
2019-05-01 18:53:33 -04:00
* rhel-8
Remove fedora 26, add 28 (#30683) * Remove fedora 26, add 28 Closes #30579 * Update testing docs with new fedora 28 image
2018-05-22 00:22:00 -04:00
* fedora-28
Add packaging tests for Fedora 29, remove 27 (#38726)
2019-02-12 07:19:27 -05:00
* fedora-29
Add quiet option to disable console logging (#20422) This commit adds a -q/--quiet option to Elasticsearch so that it does not log anything in the console and closes stdout & stderr streams. This is useful for SystemD to avoid duplicate logs in both journalctl and /var/log/elasticsearch/elasticsearch.log while still allows the JVM to print error messages in stdout/stderr if needed. closes #17220
2016-09-12 10:56:13 -04:00
* oel-6 aka Oracle Enterprise Linux 6
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
* oel-7 aka Oracle Enterprise Linux 7
BATS testing: Add SLES-12 to list of tested virtual machines This adds SuSe Linux Enterprise Server 12 to the list of tested VMs. SLES 12 is using systemd, so that the current RPM works out of the box. SLES12 however is already quite old and does not ship with java8, so this required adding an opensuse repo.
2015-09-22 08:59:39 -04:00
* sles-12
Tests: Switch to openSUSE 42 (Leap) for packaging tests openSUSE-13 has reached [EOL](https://en.opensuse.org/Lifetime). Replace openSUSE-13 with openSUSE-42 (Leap) for packaging tests and update docs. Relates #25001
2017-06-01 08:40:47 -04:00
* opensuse-42 aka Leap
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
We're missing the following from the support matrix because there aren't high
quality boxes available in vagrant atlas:
[doc] fix asciidoc format
2015-08-17 11:45:18 -04:00
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
* sles-11
[test] packaging: add windows boxes (#30402) Adds windows server 2012r2 and 2016 vagrant boxes to packaging tests. They can only be used if IDs for their images are specified, which are passed to gradle and then to vagrant via env variables. Adds options to the project property `vagrant.boxes` to choose between linux and windows boxes. Bats tests are run only on linux boxes, and portable packaging tests run on all boxes. Platform tests are only run on linux boxes since they are not being maintained. For #26741
2018-05-16 19:42:08 -04:00
=== Testing packaging on Windows
The packaging tests also support Windows Server 2012R2 and Windows Server 2016.
Unfortunately we're not able to provide boxes for them in open source use
because of licensing issues. Any Virtualbox image that has WinRM and Powershell
enabled for remote users should work.
Testing on Windows requires the https://github.com/criteo/vagrant-winrm[vagrant-winrm] plugin.
------------------------------------
vagrant plugin install vagrant-winrm
------------------------------------
Specify the image IDs of the Windows boxes to gradle with the following project
properties. They can be set in `~/.gradle/gradle.properties` like
------------------------------------
vagrant.windows-2012r2.id=my-image-id
vagrant.windows-2016.id=another-image-id
------------------------------------
or passed on the command line like `-Pvagrant.windows-2012r2.id=my-image-id`
`-Pvagrant.windows-2016=another-image-id`
These properties are required for Windows support in all gradle tasks that
Update TESTING.asciidoc for new :qa:os test style (#48023) * Update testing document for new packaging tests The TESTING.asciidoc document had gotten out of date due to some new and wonderful changes in our vagrant testing code. I've removed all of the instructions that no longer work, and added working examples and descriptions in their place.
2019-10-16 16:24:50 -04:00
handle packaging tests. Either or both may be specified.
[doc] fix asciidoc format
2015-08-17 11:45:18 -04:00
[test] packaging: add windows boxes (#30402) Adds windows server 2012r2 and 2016 vagrant boxes to packaging tests. They can only be used if IDs for their images are specified, which are passed to gradle and then to vagrant via env variables. Adds options to the project property `vagrant.boxes` to choose between linux and windows boxes. Bats tests are run only on linux boxes, and portable packaging tests run on all boxes. Platform tests are only run on linux boxes since they are not being maintained. For #26741
2018-05-16 19:42:08 -04:00
If you're running vagrant commands outside of gradle, specify the Windows boxes
with the environment variables
* `VAGRANT_WINDOWS_2012R2_BOX`
* `VAGRANT_WINDOWS_2016_BOX`
=== Testing VMs are disposable
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
Update docs for vagrant tests with new gradle task names
2016-04-06 19:08:39 -04:00
It's important to think of VMs like cattle. If they become lame you just shoot
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
them and let vagrant reprovision them. Say you've hosed your precise VM:
[doc] fix asciidoc format
2015-08-17 11:45:18 -04:00
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
----------------------------------------------------
Drop support for Ubuntu 14.04 (#40709) With the 7.0.0 release, we are dropping support for Ubuntu 14.04. This commit removes this OS from our testing infrastructure.
2019-04-02 08:51:11 -04:00
vagrant ssh ubuntu-1604 -c 'sudo rm -rf /bin'; echo oops
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
----------------------------------------------------
[doc] fix asciidoc format
2015-08-17 11:45:18 -04:00
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
All you've got to do to get another one is
[doc] fix asciidoc format
2015-08-17 11:45:18 -04:00
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
----------------------------------------------
Drop support for Ubuntu 14.04 (#40709) With the 7.0.0 release, we are dropping support for Ubuntu 14.04. This commit removes this OS from our testing infrastructure.
2019-04-02 08:51:11 -04:00
vagrant destroy -f ubuntu-1604 && vagrant up ubuntu-1604 --provider virtualbox
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
----------------------------------------------
[doc] fix asciidoc format
2015-08-17 11:45:18 -04:00
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
The whole process takes a minute and a half on a modern laptop, two and a half
without vagrant-cachier.
Its possible that some downloads will fail and it'll be impossible to restart
them. This is a bug in vagrant. See the instructions here for how to work
around it:
https://github.com/mitchellh/vagrant/issues/4479
Some vagrant commands will work on all VMs at once:
[doc] fix asciidoc format
2015-08-17 11:45:18 -04:00
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
------------------
vagrant halt
vagrant destroy -f
------------------
[test] Gradle-ify vagrant tests This gets the tar and tar_plugins tests working in gradle. It does so by adding a subproject, qa/vagrant, which adds the following tasks: Verification ------------ checkPackages - Check the packages against a representative sample of the linux distributions we have in our Vagrantfile checkPackagesAllDistros - Check the packages against all the linux distributions we have in our Vagrantfile Package Verification -------------------- checkCentos6 - Run packaging tests against centos-6 checkCentos7 - Run packaging tests against centos-7 checkDebian8 - Run packaging tests against debian-8 checkFedora22 - Run packaging tests against fedora-22 checkOel7 - Run packaging tests against oel-7 checkOpensuse13 - Run packaging tests against opensuse-13 checkSles12 - Run packaging tests against sles-12 checkUbuntu1204 - Run packaging tests against ubuntu-1204 checkUbuntu1404 - Run packaging tests against ubuntu-1404 checkUbuntu1504 - Run packaging tests against ubuntu-1504 Vagrant ------- smokeTestCentos6 - Smoke test the centos-6 VM smokeTestCentos7 - Smoke test the centos-7 VM smokeTestDebian8 - Smoke test the debian-8 VM smokeTestFedora22 - Smoke test the fedora-22 VM smokeTestOel7 - Smoke test the oel-7 VM smokeTestOpensuse13 - Smoke test the opensuse-13 VM smokeTestSles12 - Smoke test the sles-12 VM smokeTestUbuntu1204 - Smoke test the ubuntu-1204 VM smokeTestUbuntu1404 - Smoke test the ubuntu-1404 VM smokeTestUbuntu1504 - Smoke test the ubuntu-1504 VM vagrantHaltCentos6 - Shutdown the vagrant VM running centos-6 vagrantHaltCentos7 - Shutdown the vagrant VM running centos-7 vagrantHaltDebian8 - Shutdown the vagrant VM running debian-8 vagrantHaltFedora22 - Shutdown the vagrant VM running fedora-22 vagrantHaltOel7 - Shutdown the vagrant VM running oel-7 vagrantHaltOpensuse13 - Shutdown the vagrant VM running opensuse-13 vagrantHaltSles12 - Shutdown the vagrant VM running sles-12 vagrantHaltUbuntu1204 - Shutdown the vagrant VM running ubuntu-1204 vagrantHaltUbuntu1404 - Shutdown the vagrant VM running ubuntu-1404 vagrantHaltUbuntu1504 - Shutdown the vagrant VM running ubuntu-1504 vagrantSmokeTest - Smoke test some representative distros from the Vagrantfile vagrantSmokeTestAllDistros - Smoke test all distros from the Vagrantfile vagrantUpCentos6 - Startup a vagrant VM running centos-6 vagrantUpCentos7 - Startup a vagrant VM running centos-7 vagrantUpDebian8 - Startup a vagrant VM running debian-8 vagrantUpFedora22 - Startup a vagrant VM running fedora-22 vagrantUpOel7 - Startup a vagrant VM running oel-7 vagrantUpOpensuse13 - Startup a vagrant VM running opensuse-13 vagrantUpSles12 - Startup a vagrant VM running sles-12 vagrantUpUbuntu1204 - Startup a vagrant VM running ubuntu-1204 vagrantUpUbuntu1404 - Startup a vagrant VM running ubuntu-1404 vagrantUpUbuntu1504 - Startup a vagrant VM running ubuntu-1504 It does not make the "check" task depend on "checkPackages" so running the vagrant tests is still optional. They are slow and depend on vagrant and virtualbox. The Package Verification tasks are useful for testing individual distros. The Vagrant tasks are listed in `gradle tasks` primarily for discoverability.
2015-11-02 12:40:47 -05:00
`vagrant up` would normally start all the VMs but we've prevented that because
that'd consume a ton of ram.
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
[test] packaging: add windows boxes (#30402) Adds windows server 2012r2 and 2016 vagrant boxes to packaging tests. They can only be used if IDs for their images are specified, which are passed to gradle and then to vagrant via env variables. Adds options to the project property `vagrant.boxes` to choose between linux and windows boxes. Bats tests are run only on linux boxes, and portable packaging tests run on all boxes. Platform tests are only run on linux boxes since they are not being maintained. For #26741
2018-05-16 19:42:08 -04:00
=== Iterating on packaging tests
[Packaging] Run tests in vagrant This creates a module in qa called vagrant that can be run if you have vagrant and virtualbox installed and will run the packaging tests in trusty and centos-7.0. You can ask it to run tests in other linuxes. This is the full list: * precise aka Ubuntu 12.04 * trusty aka Ubuntu 14.04 * vivid aka Ubuntun 15.04 * wheezy aka Debian 7, the current debian oldstable distribution * jessie aka Debian 8, the current debina stable distribution * centos-6 * centos-7 * fedora-22 * oel-7 There is lots of documentation on how to do this in the TESTING.asciidoc. Closes #12611
2015-08-04 09:36:22 -04:00
Update TESTING.asciidoc for new :qa:os test style (#48023) * Update testing document for new packaging tests The TESTING.asciidoc document had gotten out of date due to some new and wonderful changes in our vagrant testing code. I've removed all of the instructions that no longer work, and added working examples and descriptions in their place.
2019-10-16 16:24:50 -04:00
Because our packaging tests are capable of testing many combinations of OS
(e.g., Windows, Linux, etc.), package type (e.g., zip file, RPM, etc.),
Elasticsearch distribution type (e.g., default or OSS), and so forth, it's
faster to develop against smaller subsets of the tests. For example, to run
tests for the default archive distribution on Fedora 28:
[test] java tests for archive packaging (#30734) Ports the first couple tests for archive distributions from the old bats project to the new java project that includes windows platforms, consolidating them into one test method that tests that the distributions can be extracted and their contents verified. Includes the zip distributions which were not tested in the bats project.
2018-05-23 13:37:57 -04:00
Update TESTING.asciidoc for new :qa:os test style (#48023) * Update testing document for new packaging tests The TESTING.asciidoc document had gotten out of date due to some new and wonderful changes in our vagrant testing code. I've removed all of the instructions that no longer work, and added working examples and descriptions in their place.
2019-10-16 16:24:50 -04:00
-----------------------------------------------------------
./gradlew :qa:os:fedora-28:distroTest.default-linux-archive
-----------------------------------------------------------
[TESTS] Create vagrant up task for all boxes (#22496) Currently, such tasks are only created for default boxes (centos-7, ubuntu-1404) and not all boxes and this can be misleading for developers who want to debug testing scripts on non-default boxes.
2017-01-10 03:45:33 -05:00
Update TESTING.asciidoc for new :qa:os test style (#48023) * Update testing document for new packaging tests The TESTING.asciidoc document had gotten out of date due to some new and wonderful changes in our vagrant testing code. I've removed all of the instructions that no longer work, and added working examples and descriptions in their place.
2019-10-16 16:24:50 -04:00
These test tasks can use the `--tests`, `--info`, and `--debug` parameters just like
non-OS tests can. For example:
[TESTS] Create vagrant up task for all boxes (#22496) Currently, such tasks are only created for default boxes (centos-7, ubuntu-1404) and not all boxes and this can be misleading for developers who want to debug testing scripts on non-default boxes.
2017-01-10 03:45:33 -05:00
Update TESTING.asciidoc for new :qa:os test style (#48023) * Update testing document for new packaging tests The TESTING.asciidoc document had gotten out of date due to some new and wonderful changes in our vagrant testing code. I've removed all of the instructions that no longer work, and added working examples and descriptions in their place.
2019-10-16 16:24:50 -04:00
-----------------------------------------------------------
./gradlew :qa:os:fedora-28:distroTest.default-linux-archive \
--tests "com.elasticsearch.packaging.test.ArchiveTests"
-----------------------------------------------------------
[TESTS] Create vagrant up task for all boxes (#22496) Currently, such tasks are only created for default boxes (centos-7, ubuntu-1404) and not all boxes and this can be misleading for developers who want to debug testing scripts on non-default boxes.
2017-01-10 03:45:33 -05:00
Test: Convert rolling upgrade test to have task per wire compat version (#24758) This commit changes the rolling upgrade test to create a set of rest test tasks per wire compat version. The most recent wire compat version is always tested with the `integTest` task, and all versions can be tested with `bwcTest`.
2017-05-18 04:14:24 -04:00
== Testing backwards compatibility
Backwards compatibility tests exist to test upgrading from each supported version
Upadte TESTING.ascidoc BWC section (#35126) * Upadte BWC section
2018-11-02 00:34:29 -04:00
to the current version. To run them all use:
Test: Convert rolling upgrade test to have task per wire compat version (#24758) This commit changes the rolling upgrade test to create a set of rest test tasks per wire compat version. The most recent wire compat version is always tested with the `integTest` task, and all versions can be tested with `bwcTest`.
2017-05-18 04:14:24 -04:00
-------------------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew bwcTest
Test: Convert rolling upgrade test to have task per wire compat version (#24758) This commit changes the rolling upgrade test to create a set of rest test tasks per wire compat version. The most recent wire compat version is always tested with the `integTest` task, and all versions can be tested with `bwcTest`.
2017-05-18 04:14:24 -04:00
-------------------------------------------------
Upadte TESTING.ascidoc BWC section (#35126) * Upadte BWC section
2018-11-02 00:34:29 -04:00
A specific version can be tested as well. For example, to test bwc with
Test: Convert rolling upgrade test to have task per wire compat version (#24758) This commit changes the rolling upgrade test to create a set of rest test tasks per wire compat version. The most recent wire compat version is always tested with the `integTest` task, and all versions can be tested with `bwcTest`.
2017-05-18 04:14:24 -04:00
version 5.3.2 run:
-------------------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew v5.3.2#bwcTest
Test: Convert rolling upgrade test to have task per wire compat version (#24758) This commit changes the rolling upgrade test to create a set of rest test tasks per wire compat version. The most recent wire compat version is always tested with the `integTest` task, and all versions can be tested with `bwcTest`.
2017-05-18 04:14:24 -04:00
-------------------------------------------------
Upadte TESTING.ascidoc BWC section (#35126) * Upadte BWC section
2018-11-02 00:34:29 -04:00
Tests are ran for versions that are not yet released but with which the current version will be compatible with.
These are automatically checked out and built from source.
See link:./buildSrc/src/main/java/org/elasticsearch/gradle/VersionCollection.java[VersionCollection]
Update TESTING.asciidoc for new :qa:os test style (#48023) * Update testing document for new packaging tests The TESTING.asciidoc document had gotten out of date due to some new and wonderful changes in our vagrant testing code. I've removed all of the instructions that no longer work, and added working examples and descriptions in their place.
2019-10-16 16:24:50 -04:00
and link:./distribution/bwc/build.gradle[distribution/bwc/build.gradle]
Upadte TESTING.ascidoc BWC section (#35126) * Upadte BWC section
2018-11-02 00:34:29 -04:00
for more information.
When running `./gradlew check`, minimal bwc checks are also run against compatible versions that are not yet released.
[TESTS] Create vagrant up task for all boxes (#22496) Currently, such tasks are only created for default boxes (centos-7, ubuntu-1404) and not all boxes and this can be misleading for developers who want to debug testing scripts on non-default boxes.
2017-01-10 03:45:33 -05:00
Upadte TESTING.ascidoc BWC section (#35126) * Upadte BWC section
2018-11-02 00:34:29 -04:00
==== BWC Testing against a specific remote/branch
Allow BWC Testing against a specific branch (#25510) Some times we need a fix / change to have two parts in two different branches (corresponding to two different ES releases). In order to be able to test these cases you need to run the BWC tests against a local branch rather than then using a branch from `github.com/elastic/elasticsearch`. This commit adds a system property called `tests.bwc.refspec` that allows you to do it. Note that I've chosen to go with the simplest code change for now, at the expense of some user friendliness.
2017-07-07 05:18:03 -04:00
Sometimes a backward compatibility change spans two versions. A common case is a new functionality
Build: Use branch specific refspec sysprop for bwc builds (#29299) This commit changes the sysprop for overriding the branch bwc builds use to be branch specific. There are 3 different bwc branches built, but all of them currently read the exact same sysprop. For example, with this change and current branches, you can now specify eg `-Dtests.bwc.refspec.6.x=my_6x` and it will build only next-minor-snapshot with that branch, while next-bugfix-snapshot will continue to use 5.6.
2018-03-29 14:59:52 -04:00
that needs a BWC bridge in an unreleased versioned of a release branch (for example, 5.x).
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
To test the changes, you can instruct Gradle to build the BWC version from a another remote/branch combination instead of
Rename system property to change bwc checkout behavior (#45574)
2019-08-16 11:43:14 -04:00
pulling the release branch from GitHub. You do so using the `bwc.remote` and `bwc.refspec.BRANCH` system properties:
Allow BWC Testing against a specific branch (#25510) Some times we need a fix / change to have two parts in two different branches (corresponding to two different ES releases). In order to be able to test these cases you need to run the BWC tests against a local branch rather than then using a branch from `github.com/elastic/elasticsearch`. This commit adds a system property called `tests.bwc.refspec` that allows you to do it. Note that I've chosen to go with the simplest code change for now, at the expense of some user friendliness.
2017-07-07 05:18:03 -04:00
-------------------------------------------------
Rename system property to change bwc checkout behavior (#45574)
2019-08-16 11:43:14 -04:00
./gradlew check -Dbwc.remote=${remote} -Dbwc.refspec.5.x=index_req_bwc_5.x
Allow BWC Testing against a specific branch (#25510) Some times we need a fix / change to have two parts in two different branches (corresponding to two different ES releases). In order to be able to test these cases you need to run the BWC tests against a local branch rather than then using a branch from `github.com/elastic/elasticsearch`. This commit adds a system property called `tests.bwc.refspec` that allows you to do it. Note that I've chosen to go with the simplest code change for now, at the expense of some user friendliness.
2017-07-07 05:18:03 -04:00
-------------------------------------------------
Enable BWC testing against other remotes This commit enables BWC testing against remotes on GitHub other than elastic/elasticsearch.git. Relates #26918
2017-10-07 13:40:18 -04:00
The branch needs to be available on the remote that the BWC makes of the
repository you run the tests from. Using the remote is a handy trick to make
sure that a branch is available and is up to date in the case of multiple runs.
Allow BWC Testing against a specific branch (#25510) Some times we need a fix / change to have two parts in two different branches (corresponding to two different ES releases). In order to be able to test these cases you need to run the BWC tests against a local branch rather than then using a branch from `github.com/elastic/elasticsearch`. This commit adds a system property called `tests.bwc.refspec` that allows you to do it. Note that I've chosen to go with the simplest code change for now, at the expense of some user friendliness.
2017-07-07 05:18:03 -04:00
Example:
Enable BWC testing against other remotes This commit enables BWC testing against remotes on GitHub other than elastic/elasticsearch.git. Relates #26918
2017-10-07 13:40:18 -04:00
Say you need to make a change to `master` and have a BWC layer in `5.x`. You
will need to:
. Create a branch called `index_req_change` off your remote `${remote}`. This
will contain your change.
Allow BWC Testing against a specific branch (#25510) Some times we need a fix / change to have two parts in two different branches (corresponding to two different ES releases). In order to be able to test these cases you need to run the BWC tests against a local branch rather than then using a branch from `github.com/elastic/elasticsearch`. This commit adds a system property called `tests.bwc.refspec` that allows you to do it. Note that I've chosen to go with the simplest code change for now, at the expense of some user friendliness.
2017-07-07 05:18:03 -04:00
. Create a branch called `index_req_bwc_5.x` off `5.x`. This will contain your bwc layer.
Enable BWC testing against other remotes This commit enables BWC testing against remotes on GitHub other than elastic/elasticsearch.git. Relates #26918
2017-10-07 13:40:18 -04:00
. Push both branches to your remote repository.
Rename system property to change bwc checkout behavior (#45574)
2019-08-16 11:43:14 -04:00
. Run the tests with `./gradlew check -Dbwc.remote=${remote} -Dbwc.refspec.5.x=index_req_bwc_5.x`.
Allow BWC Testing against a specific branch (#25510) Some times we need a fix / change to have two parts in two different branches (corresponding to two different ES releases). In order to be able to test these cases you need to run the BWC tests against a local branch rather than then using a branch from `github.com/elastic/elasticsearch`. This commit adds a system property called `tests.bwc.refspec` that allows you to do it. Note that I've chosen to go with the simplest code change for now, at the expense of some user friendliness.
2017-07-07 05:18:03 -04:00
Upadte TESTING.ascidoc BWC section (#35126) * Upadte BWC section
2018-11-02 00:34:29 -04:00
==== Skip fetching latest
Enable skipping fetching latest for BWC builds (#29497) The BWC builds always fetch the latest from the elastic/elasticsearch repository for the BWC branches. Yet, there are use-cases for using the local checkout without fetching the latest. This commit enables these use-cases by adding a tests.bwc.git.fetch.latest property to skip the fetches.
2018-04-13 09:31:06 -04:00
For some BWC testing scenarios, you want to use the local clone of the
repository without fetching latest. For these use cases, you can set the system
property `tests.bwc.git_fetch_latest` to `false` and the BWC builds will skip
fetching the latest from the remote.
Add guidance for writing tests. (#39318)
2019-03-01 09:13:39 -05:00
== How to write good tests?
=== Base classes for test cases
There are multiple base classes for tests:
Fix formatting of TESTING.asciidoc.
2019-03-01 09:16:52 -05:00
* **`ESTestCase`**: The base class of all tests. It is typically extended
directly by unit tests.
* **`ESSingleNodeTestCase`**: This test case sets up a cluster that has a
single node.
* **`ESIntegTestCase`**: An integration test case that creates a cluster that
might have multiple nodes.
* **`ESRestTestCase`**: An integration tests that interacts with an external
cluster via the REST API. For instance, YAML tests run via sub classes of
`ESRestTestCase`.
Add guidance for writing tests. (#39318)
2019-03-01 09:13:39 -05:00
=== Good practices
==== What kind of tests should I write?
Unit tests are the preferred way to test some functionality: most of the time
they are simpler to understand, more likely to reproduce, and unlikely to be
affected by changes that are unrelated to the piece of functionality that is
being tested.
The reason why `ESSingleNodeTestCase` exists is that all our components used to
be very hard to set up in isolation, which had led us to having a number of
integration tests but close to no unit tests. `ESSingleNodeTestCase` is a
workaround for this issue which provides an easy way to spin up a node and get
access to components that are hard to instantiate like `IndicesService`.
Whenever practical, you should prefer unit tests.
Many tests extend `ESIntegTestCase`, mostly because this is how most tests used
to work in the early days of Elasticsearch. However the complexity of these
tests tends to make them hard to debug. Whenever the functionality that is
being tested isn't intimately dependent on how Elasticsearch behaves as a
cluster, it is recommended to write unit tests or REST tests instead.
In short, most new functionality should come with unit tests, and optionally
REST tests to test integration.
==== Refactor code to make it easier to test
Unfortunately, a large part of our code base is still hard to unit test.
Sometimes because some classes have lots of dependencies that make them hard to
instantiate. Sometimes because API contracts make tests hard to write. Code
refactors that make functionality easier to unit test are encouraged. If this
sounds very abstract to you, you can have a look at
https://github.com/elastic/elasticsearch/pull/16610[this pull request] for
instance, which is a good example. It refactors `IndicesRequestCache` in such
a way that:
- it no longer depends on objects that are hard to instantiate such as
`IndexShard` or `SearchContext`,
- time-based eviction is applied on top of the cache rather than internally,
which makes it easier to assert on what the cache is expected to contain at
a given time.
=== Bad practices
==== Use randomized-testing for coverage
In general, randomization should be used for parameters that are not expected
to affect the behavior of the functionality that is being tested. For instance
the number of shards should not impact `date_histogram` aggregations, and the
choice of the `store` type (`niofs` vs `mmapfs`) does not affect the results of
a query. Such randomization helps improve confidence that we are not relying on
implementation details of one component or specifics of some setup.
However it should not be used for coverage. For instance if you are testing a
piece of functionality that enters different code paths depending on whether
the index has 1 shards or 2+ shards, then we shouldn't just test against an
index with a random number of shards: there should be one test for the 1-shard
case, and another test for the 2+ shards case.
==== Abuse randomization in multi-threaded tests
Multi-threaded tests are often not reproducible due to the fact that there is
no guarantee on the order in which operations occur across threads. Adding
randomization to the mix usually makes things worse and should be done with
care.
Docs: Update generating test coverage reports (#29255) Old docs said to use maven. That doesn't work. We can't generate the reports right now.
2018-03-27 17:29:19 -04:00
== Test coverage analysis
Fix coverage analysis. Two versions of jacoco were being used and creating jar hell
2015-08-03 23:08:18 -04:00
Docs: Update generating test coverage reports (#29255) Old docs said to use maven. That doesn't work. We can't generate the reports right now.
2018-03-27 17:29:19 -04:00
Generating test coverage reports for Elasticsearch is currently not possible through Gradle.
Update TESTING.asciidoc for new :qa:os test style (#48023) * Update testing document for new packaging tests The TESTING.asciidoc document had gotten out of date due to some new and wonderful changes in our vagrant testing code. I've removed all of the instructions that no longer work, and added working examples and descriptions in their place.
2019-10-16 16:24:50 -04:00
However, it _is_ possible to gain insight in code coverage using IntelliJ's built-in coverage
Docs: Update generating test coverage reports (#29255) Old docs said to use maven. That doesn't work. We can't generate the reports right now.
2018-03-27 17:29:19 -04:00
analysis tool that can measure coverage upon executing specific tests. Eclipse may also be able
to do the same using the EclEmma plugin.
doc how to get code coverage for unit,integ,combined
2015-09-01 20:57:08 -04:00
Docs: Update generating test coverage reports (#29255) Old docs said to use maven. That doesn't work. We can't generate the reports right now.
2018-03-27 17:29:19 -04:00
Test coverage reporting used to be possible with JaCoCo when Elasticsearch was using Maven
as its build system. Since the switch to Gradle though, this is no longer possible, seeing as
the code currently used to build Elasticsearch does not allow JaCoCo to recognize its tests.
For more information on this, see the discussion in https://github.com/elastic/elasticsearch/issues/28867[issue #28867].
doc how to get code coverage for unit,integ,combined
2015-09-01 20:57:08 -04:00
Add documentation on remote debugging For a node which is launched outside the context of Gradle.
2017-01-13 08:57:40 -05:00
== Debugging remotely from an IDE
Update doc after review
2017-01-16 04:26:12 -05:00
If you want to run Elasticsearch and be able to remotely attach the process
for debugging purposes from your IDE, can start Elasticsearch using `ES_JAVA_OPTS`:
Add documentation on remote debugging For a node which is launched outside the context of Gradle.
2017-01-13 08:57:40 -05:00
---------------------------------------------------------------------------
Update doc after review
2017-01-16 04:26:12 -05:00
ES_JAVA_OPTS="-Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=4000,suspend=y" ./bin/elasticsearch
Add documentation on remote debugging For a node which is launched outside the context of Gradle.
2017-01-13 08:57:40 -05:00
---------------------------------------------------------------------------
Update doc after review
2017-01-16 04:26:12 -05:00
Read your IDE documentation for how to attach a debugger to a JVM process.
Add documentation on remote debugging For a node which is launched outside the context of Gradle.
2017-01-13 08:57:40 -05:00
Build: Change project attachment into special extra-plugins dir Currently we use the "gradle project attachment plugin" to support building elasticsearch as part of another project. However, this plugin has a number of issues, a large part of which is requiring consistent use of the projectsPrefix. This change removes projectsPrefix, and adds support for a special extra-plugins directory in the root of elasticsearch. Any projects checked out within this directory will be automatically added to elasticsearch.
2015-11-20 14:58:50 -05:00
== Building with extra plugins
Additional plugins may be built alongside elasticsearch, where their
dependency on elasticsearch will be substituted with the local elasticsearch
Build: Remove hardcoded reference to x-plugins in build (#21773) * Build: Remove hardcoded reference to x-plugins in build The gradle build currenlty allows extra plugins to be hooked into the elasticsearch build by placing under an x-plugins directory as a sibling of the elasticsearch checkout. This change converts this directory to one called elasticsearch-extra. The subdirectories of elasticsearch-extra become first level projects in gradle (while before they would have been subprojects of `:x-plugins`. Additionally, this allows major version checkouts to be associated with extra plugins. For example, you could have elasticsearch checked out as `elasticsearch-5.x`, and a sibling `elasticsearch-5.x-extra` directory.
2016-12-14 18:02:07 -05:00
build. To add your plugin, create a directory called elasticsearch-extra as
a sibling of elasticsearch. Checkout your plugin underneath elasticsearch-extra
and the build will automatically pick it up. You can verify the plugin is
included as part of the build by checking the projects of the build.
Build: Change project attachment into special extra-plugins dir Currently we use the "gradle project attachment plugin" to support building elasticsearch as part of another project. However, this plugin has a number of issues, a large part of which is requiring consistent use of the projectsPrefix. This change removes projectsPrefix, and adds support for a special extra-plugins directory in the root of elasticsearch. Any projects checked out within this directory will be automatically added to elasticsearch.
2015-11-20 14:58:50 -05:00
---------------------------------------------------------------------------
Update testing docs to reflect Gradle wrapper This commit updates the testing docs to reflect the usage of the Gradle wrapper. Relates #28107
2018-01-05 17:19:34 -05:00
./gradlew projects
Build: Change project attachment into special extra-plugins dir Currently we use the "gradle project attachment plugin" to support building elasticsearch as part of another project. However, this plugin has a number of issues, a large part of which is requiring consistent use of the projectsPrefix. This change removes projectsPrefix, and adds support for a special extra-plugins directory in the root of elasticsearch. Any projects checked out within this directory will be automatically added to elasticsearch.
2015-11-20 14:58:50 -05:00
---------------------------------------------------------------------------
[DOC] macOS localhost resolve for integ tests
2017-08-23 04:59:25 -04:00
== Environment misc
There is a known issue with macOS localhost resolve strategy that can cause
some integration tests to fail. This is because integration tests have timings
for cluster formation, discovery, etc. that can be exceeded if name resolution
takes a long time.
To fix this, make sure you have your computer name (as returned by `hostname`)
inside `/etc/hosts`, e.g.:
....
127.0.0.1 localhost ElasticMBP.local
255.255.255.255 broadcasthost
::1 localhost ElasticMBP.local`
....
Add a note how to benchmark Elasticsearch With this commit we add a note that explains when to use benchmarks and point the reader to the macrobenchmarking tool Rally for further information. Relates #37694
2019-01-23 06:15:00 -05:00
== Benchmarking
For changes that might affect the performance characteristics of Elasticsearch
you should also run macrobenchmarks. We maintain a macrobenchmarking tool
called https://github.com/elastic/rally[Rally]
which you can use to measure the performance impact. It comes with a set of
default benchmarks that we also
https://elasticsearch-benchmarks.elastic.co/[run every night]. To get started,
please see https://esrally.readthedocs.io/en/stable/[Rally's documentation].
[DOCS] Add docs build info to TESTING.asciidoc (#52271) Adds a brief section about Elasticsearch docs and how users can test/build them locally.
2020-02-12 12:59:24 -05:00
== Test doc builds
The Elasticsearch docs are in AsciiDoc format. You can test and build the docs
locally using the Elasticsearch documentation build process. See
https://github.com/elastic/docs.