* 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 |
||
---|---|---|
.. | ||
acceptance | ||
docker | ||
integration | ||
rspec | ||
scripts/windows | ||
support | ||
.gitignore | ||
.rspec | ||
Gemfile | ||
Rakefile | ||
README.md |
Acceptance test Framework
The acceptance test framework for Logstash is intended to test the functionality of packages (.deb
, .rpm
)
on various supported platforms.
In this small README we describe its features and the steps necessary for executing it and adding new tests.
Description
In summary this test framework is composed of:
- A collection of rspec helpers and matchers that make creating tests easy.
- Rspecs helpers that execute commands.
The tests are expected to be executed on the target environment e.g. an Ubuntu 22.04 vm.
Running tests/Prerequisites
To run the tests from a fresh Logstash checkout, you need to:
./gradlew clean boostrap
2a. Build the necessary package artifacts e.g.rake artifact:deb
OR 2b. Supply a directory where pregenerated package artifacts exit via theLS_ARTIFACTS_PATH
environment variable (relative and absolute paths are supported).cd qa
bundle install
Now you are ready to kick off the tests:
rake qa:acceptance:all
.
Steps 1, 2b, 3, 4, 5 are executed by the ci/acceptance_tests.sh
script.
Architecture of the Framework
Directory structure
acceptance/
: all the specs definitions.rspec
: all framework parts necessary to get the test running. Includes the commands, the rspec matchers and a collection of useful helpers.
I want to add a test, what should I do?
To add a test you basically should start by the acceptance directory, here you will find an already created tests, most important locations here are:
lib
here is where the tests are living. If a test is not going to be reused it should be created here.shared_examples
inside that directory should be living all tests that could be reused in different scenarios, like you can see the CLI ones.
but we want to write tests, here is an example of how do they look like, including the different moving parts we encounter in the framework.
logstash = ServiceTester::Artifact.new()
## your test code goes here.
# example:
it_behaves_like "installable_with_jdk", logstash
it_behaves_like "updated", logstash, from_release_branch="7.17"
Inside the rspec
directory you will find a
collection of commands, organized per operating system, which
will let you operate and get your tests done.
You'll probably find enough supporting classes for different platforms, but if not, feel free to add more.
An example of an install command on debian looks like:
def installed?(package)
stdout = ""
cmd = sudo_exec!("dpkg -s #{package}")
stdout = cmd.stdout
stdout.match(/^Package: #{package}$/)
stdout.match(/^Status: install ok installed$/)
end
end
this is how we run operations and wrap them as ruby code.
Running a test (detailed level)
There is also the possibility to run your tests with more granularity by
using the rspec
command, this will let you for example run a single
tests, a collection of them using filtering, etc.
Check https://relishapp.com/rspec/rspec-core/v/3-4/docs/command-line for more details, but here is a quick cheat sheet to run them:
Run the examples that get "is installed" in their description
- bundle exec rspec acceptance/spec -e "is installed"
Run the example defined at line 11
- bundle exec rspec acceptance/spec/lib/artifact_operation_spec.rb:11