* Provision automatic test runs for ruby/java unit tests and integration tests with fips mode (#17029) * Run ruby unit tests under FIPS mode This commit shows a proposed pattern for running automated tests for logstash in FIPS mode. It uses a new identifier in gradle for conditionally setting properties to configure fips mode. The tests are run in a container representative of the base image the final artifacts will be built from. * Move everything from qa/fips -> x-pack This commit moves test setup/config under x-pack dir. * Extend test pipelines for fips mode to java unit tests and integration * Add git to container for gradle * move fips-mode gradle hooks to x-pack * Skip license check for now --------- Co-authored-by: Ry Biesemeyer <ry.biesemeyer@elastic.co> * Split fips integration tests into two steps (#17038) * Split fips integration tests into two steps The integration tests suite takes about 40 minutes. This is far too slow for reasonable feedback on a PR. This commit follows the pattern for the non-fips integration tests whereby the tests are split into two sections that can run in parallel across two steps. This should halve the feedback time. The logic for getting a list of specs files to run has been extracted to a shared shell script for use here and in the integration tests shell script. * Use shared function for splitting integration tests The logic for getting a list of specs to run has been extracted so that it can be shared across fips and non fips integration test modes. This commit updates the non fips integration tests to use the shared function. * fix typo in helper name (kebab case, not snake) * Escape $ so buildkite upload does not try to interpolate * Wrap integration tests in shell script to avoid BK interpolation * Move entrypoint for running integration tests inside docker * Skip offline pack manager tests when running in fips mode (#17160) This commit introduces a pattern for skipping tests we do not want to run in fips mode. In this case the plugin manager tests rely on using bundler/net-http/openssl which is not configured to be run with bouncycastle fips providers. * Get tests running in FIPS environment (#17096) * Modify FIPS test runner environment for integration tests This commit makes two small changes to the dockerfile used to define the fips test environment. Specifically it adds curl (which is required by integration tests), make (which is required by test setup), adds a c compiler (gcc and glibc for integration tests which compile a small c program) and turns off debug ssl logging as it is extremely noisy in logs and breaking some assumptions in tests about logfile content. Closes https://github.com/elastic/ingest-dev/issues/5074 * Do not run test env as root The elastic stack is not meant to be run as root. This commit updates the test environment to provision a non root user and have the container context execute under that providioned user. Closes https://github.com/elastic/ingest-dev/issues/5088 * Skip unit tests that reach out to rubygems for fips mode The `update` test setup reaches out to rubygems with net/http which is incompatible with our use of openssl in fips mode. This commit skips those tests when running under fips. See https://github.com/elastic/ingest-dev/issues/5071 * Work around random data request limits in BCFIPS This commit changes test setup to make chunked calls to random data generation in order to work around a limit in fips mode. See https://github.com/elastic/ingest-dev/issues/5072 for details. * Skip tests validating openssl defaults Openssl will not be used when running under FIPS mode. The test setup and tests themselves were failing when running in FIPS mode. This commit skips the tests that are covering behavior that will be disabled. See https://github.com/elastic/ingest-dev/issues/5069 * Skip tests that require pluginmanager to install plugins This commit skips tests that rely on using the pluginmanager to install plugins during tests which require reaching out to rubygems. See https://github.com/elastic/ingest-dev/issues/5108 * Skip prepare offline pack integration tests in fips mode The offline pack tests require on pluginmanager to use net-http library for resolving deps. This will not operate under fips mode. Skip when running in fips mode. See https://github.com/elastic/ingest-dev/issues/5109 * Ensure a gem executible is on path for test setup This commit modifies the generate-gems script to ensure that a `gem` executable is on the path. If there is not one on the test runner, then use the one bundled with vendored jruby. * Skip webserver specs when running in FIPS mode This commit skips the existing webserver tests. We have some options and need to understand some requirements for the webserver functionality for fips mode. The https://github.com/elastic/ingest-dev/issues/5110 issue has a ton of details. * Skip cli `remove` integration tests for FIPS This commit skips tests that are running `remove` action for the pluginmanager. These require reaching out to rubygems which is not available in FIPS mode. These tests were added post initial integration tests scoping work but are clearly requiring skips for FIPS mode. * Add openssl package to FIPS testing env container The setup script for filebeats requires an openssl executable. This commit updates the testing container with this tool. See https://github.com/elastic/ingest-dev/issues/5107 * Re-introduce retries for FIPS tests now that we are in a passing state * Backport 17203 and 17267 fedramp8x (#17271) * Pluginmanager clean after mutate (#17203) * pluginmanager: always clean after mutate * pluginmanager: don't skip updating plugins installed with --version * pr feedback (cherry picked from commit |
||
---|---|---|
.. | ||
fixtures | ||
framework | ||
services | ||
specs | ||
src/test/java/org/logstash/integration | ||
.gitignore | ||
.rspec | ||
build.gradle | ||
Gemfile | ||
gradle.properties | ||
integration_tests.gemspec | ||
logstash.keystore | ||
README.md | ||
rspec.rb | ||
settings.gradle | ||
suite.yml |
Logstash Integration Tests aka RATS
These test sets are full integration tests. They can:
- start Logstash from a binary,
- run configs using
-e
, and - use external services such as Kafka, Elasticsearch, and Beats.
This framework is hybrid -- a combination of bash scripts (to mainly setup services), Ruby service files, and RSpec. All test assertions are done in RSpec.
Environment setup
Directory Layout
fixtures
: Specify services to run, Logstash config, and test specific scripts ala.travis.yml
. You test settings in form oftest_name.yml
.services
: This directory has bash scripts that download and bootstrap binaries for services. This is where services like Elasticsearch will be downloaded and run. Service can have 3 files:<service>_setup.sh
,<service>_teardown.sh
and<service>
.rb. The bash scripts deal with downloading and bootstrapping, but the ruby source will trigger them from the test as a shell out (using backticks). The tests are blocked until the setup/teardown completes. For example, Elasticsearch service haselasticsearch_setup.sh
,elasticsearch_teardown.sh
andelasticsearch.rb
. The service name in yml is "elasticsearch".framework
: Test framework source code.specs
: Rspec tests that use services and validates stuff
Setup Java
The integration test scripts use gradle
to run the tests.
Gradle requires a valid version of Java either on the system path, or specified using the JAVA_HOME
environment variable pointing to the location of a valid JDK.
To run integration tests using a different version of Java, set the BUILD_JAVA_HOME
environment variable to the location of the JDK that you wish to test with.
Testing on Mac/Linux
Dependencies
JRuby
rspec
rake
bundler
Running integration tests locally (Mac/Linux)
Run tests from the Logstash root directory.
-
Run all tests:
ci/integration_tests.sh
-
Run a single test:
ci/integration_tests.sh specs/es_output_how_spec.rb
-
Debug tests:
ci/integration_tests.sh setup cd qa/integration bundle exec rspec specs/es_output_how_spec.rb (single test) bundle exec rspec specs/* (all tests)
Testing with Docker
Dependencies
Docker
Running integration tests locally using Docker
Run tests from the Logstash root directory.
-
Run all tests:
docker build -t logstash-integration-tests . docker run -it --rm logstash-integration-tests ci/integration_tests.sh
-
Run a single test:
docker build -t logstash-integration-tests .
docker run -it --rm logstash-integration-tests ci/integration_tests.sh specs/es_output_how_spec.rb
- Debug tests:
(Mac/Linux) docker ps --all -q -f status=exited | xargs docker rm
(Windows) `docker ps -a` and take note of any exited containers, then `docker rm <container-id>`
docker build -t logstash-integration-tests .
docker run -d --name debug logstash-integration-tests tail -f /dev/null
docker exec -it debug ci/integration_tests.sh setup
docker exec -it debug bash
cd qa/integration
bundle exec rspec specs/es_output_how_spec.rb
exit
docker kill debug
docker rm debug
Docker clean up (Mac/Linux)
WARNING: Docker cleanup removes all images and containers except for the logstash-base
container!
ci/docker_prune.sh
Testing on Windows
The integration tests should be run from MacOS or Linux. However, the tests can be run locally within Docker on Windows.
Adding a new test
- Creating a new test -- lets use as example. Call it "test_file_input" which brings up LS to read from a file and assert file contents (file output) were as expected.
- You'll have to create a yml file in
fixtures
calledtest_file_input_spec.yml
. Here you define any external services you need and any LS config. - Create a corresponding
test_file_input_spec.rb
inspecs
folder and use thefixtures
object to get all services, config etc. The.yml
and rspec file has to be the same name for the settings to be picked up. You can start LS inside the tests and assume all external services have already been started. - Write rspec code to validate.