Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[SLO] [Alerting] deployment agnostic slo burn rate rule tests (elasti…
…c#187924) Addresses elastic#179549 Relates to elastic#183113 ## Update Since the Appex QA team has taken on deployment agnostic tests, a lot of the original implementation of this PR has changed. Now that the Appex QA team has provided a current directly to write deployment agnostic tests, the burn rate rule tests have been moved here. To finish onboarding the burn rate rule test to this new framework, the following was done. 1. Add an `oblt.stateful.config.ts` file to complement the existing `oblt.serverless.config.ts` file to ensure the tests are run in CI 2. Ensure our test config is added to the buildkite pipepline 3. Add the alerting service to the new `deployment_agnostic/services` directory. 4. Port the tests over to the new `deployment_agnostic` directory To run serverless ``` node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts --grep="Burn rate rule" ``` To run stateful ``` node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts --grep="Burn rate rule" ``` For context, I've kept the history from the original PR description below. ## 🍒 History A new type of config file will be allowed for API integration and functional tests within the `x-pack/test` folder, using a pattern of `*.serverless.config.ts` — these config files will specify configuration needed to run a set of tests in a serverless deployment context. FTR tests already make use of the `it.tags(['my-tag-1', 'my-tag-2'])` pattern, and so we would like to stay with that pattern rather than introducing a new type of mocha tag in the it block's "description" as it was introduced in this [POC](elastic#183113). The difference with the previous PR in terms of tagging is that we use `suiteTags` instead of `mochaOps` Adding following in the config files: **serverless config** ``` suiteTags: { include: ['serverless'], }, ``` **ess config** ``` suiteTags: { include: ['ess'], }, ``` and then adding `this.tags(['serverless', 'ess'])` in the test suite instructs the test runner to run the same test suite in both environments. In order to keep things simple, we stay with the current skip approach, which means that flaky tests will be skipped for all environments by appending .skip() to the suite or to specific test cases. ## Description - This PR uses `suiteTags` for tagging the tests appropriately. We decide through following labels in which environment the tests are going to be executed: - **@ess**: Runs in an ESS environment (on-prem installation) as part of the CI validation on PRs. - **@serverless**: Runs in a serverless environment. - It introduces a new folder `x-pack/test/observability_solution_api_integration` which will serve as a centralized location for all tests by obs-ux-management team that must be run in Serverless and ESS environments. A list of all tests can be found in the R&D [issue](elastic#179549) - Within this folder, there is a "**config**" subdirectory that stores base configurations specific to both the Serverless and ESS environments. These configurations build upon the base configuration provided by test_serverless and api_integration, incorporating additional settings such as environment variables and tagging options. - The file `x-pack/test/observability_solution_api_integration/test_suites/alerting/burn_rate/burn_rate_rule.ts` is functional in both Serverless and ESS - It removes the existing burn rate rule from `x-pack/test_serverless/api_integration/test_suites/observability/alerting/burn_rate/burn_rate_rule.ts` - The `alertingApi` and `sloApi` services are moved to `test/api_integration` servers In the screenshot below you can see the `test_suites` folder structure, after having migrated the current slo burn rate rule. We recommend having an `alerting` and `slo` subfolders. Rest observability apps could be added as another subfolder under test_suites. As part of this PR, the `alerting > burn_rate` subfolders are created. <img width="376" alt="Screenshot 2024-05-13 at 09 21 28" src="https://github.com/elastic/kibana/assets/2852703/3ccaf0a5-1443-4bad-ad06-daa347488bf1"> ## How to run locally You can navigate into the new `observability_solution_api_integration` folder and use following commands to run the tests in serverless and ess environments accordingly. You can find more information in the README file of the observability_solution_api_integration folder. ``` cd x-pack/test/observability_solution_api_integration // SERVERLESS npm run alerting_burn_rate:server:serverless npm run alerting_burn_rate:runner:serverless // ESS npm run alerting_burn_rate:server:ess npm run alerting_burn_rate:runner:ess ``` ## CI - It includes a new entry in the `ftr_configs.yml` to execute the newly added tests in the pipeline. - It involves the addition of `suiteTags` in both serverless/config.base.ts and ess/config.base.ts. In the case of serverless, it includes **@serverless** while excluding **@skipInServerless**. Similarly, for ess, it includes **@ess** and excludes **@skipInEss**. ## Quality Gates and MKI pipeline The Platform team will support config files within `x-pack/test` folder with a pattern of `*.serverless.config.ts`, so these tests will be included in Kibana's Quality gates and will be run against a real MKI environment. --------- Co-authored-by: Dominique Belcher <dominique.clarke@elastic.co> Co-authored-by: Dominique Clarke <doclarke71@gmail.com> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co> Co-authored-by: Robert Oskamp <traeluki@gmail.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
- Loading branch information