mirror of
https://github.com/elastic/kibana.git
synced 2025-04-23 17:28:26 -04:00
c6b594cfee
## Summary This PR establishes the baseline to execute Cypress tests in the new `search_ai_lake` tier. ## Changes Introduced - All tests under `x-pack/test/security_solution_cypress/cypress/e2e/ai4dsoc` will be executed using the new tier by default. - These tests will run as part of the PR process within the `Serverless AI4DSOC - Security Solution Cypress Tests` execution. ## Adding a New Test To add a new test, follow these guidelines: - Read the [README](x-pack/test/security_solution_cypress/cypress/e2e/ai4dsoc/README.md). - Inside the `AI4DSOC` folder, we should have different subfolders representing the various AI4DSOC functionalities. - Each subfolder should have ownership by either an area team or the developers actively working on it. - Make sure that any functionality you want to be tested in the new tier is added inside the `AI4DSOC` folder; otherwise, that functionality will be tested using the complete tier. ## Running Tests Locally Run the tests with the following Yarn scripts from `x-pack/test/security_solution_cypress`: ```sh yarn cypress:open:ai4dsoc:serverless ``` Opens the Cypress UI with all tests in the `e2e/ai4dsoc` directory. This also runs a mocked serverless environment using the `ai_soc` product line and `search_ai_lake` tier by default. ```sh yarn cypress:run:ai4dsoc:serverless ``` Runs all tests tagged as @serverless in the e2e/ai4dsoc directory in headless mode using the ai_soc product line and search_ai_lake tier by default. ## Key Considerations - All tests must have the `@serverless` tag to be executed as part of the PR process. - MKI is not yet supported for test execution. - The AI4DSOC Cypress tests will be executed each time there is a change in one of its [dependencies](https://github.com/elastic/kibana/blob/main/.buildkite/scripts/pipelines/pull_request/pipeline.ts). - All tests are executed by default using the `platform_engineer` role. - Temporary Ownership: The Security Engineering Productivity team will own the entire AI4DSOC testing folder initially to ensure structure and best practices. Once all teams understand the workflow, this ownership will be removed. - Execution Time: If test execution in a PR takes more than 45 minutes, parallelism should be increased in the new `.buildkite/pipelines/pull_request/security_solution/ai4dsoc.yml` file. ## Security Engineering Productivity Codeownership Responsibilities The Security Engineering Productivity team should ensure: - Best practices are followed. - All tests are placed inside a functionality subfolder. - Each functionality subfolder has designated code owners. - Tests include the `@serverless` label. - The execution of AI4DSOC tests does not exceed 45 minutes. ## Follow-Up Tasks - Remove the dummy test (@tomsonpl feel free to delete it when you need to add new tests to the navigation). - Integrate tests into the periodic pipeline. - Add tests to the Kibana QA quality gate. - Update the README with MKI instructions once tests are added to the periodic pipeline and Kibana QA quality gate. - Clarify which roles will be used for the AI4DSOC effort and update the tests accordingly. |
||
|---|---|---|
| .. | ||
| hooks | ||
| pipeline-resource-definitions | ||
| pipeline-utils | ||
| pipelines | ||
| scripts | ||
| .mocharc.json | ||
| .npmrc | ||
| disabled_jest_configs.json | ||
| ftr_base_serverless_configs.yml | ||
| ftr_configs_manifests.json | ||
| ftr_oblt_serverless_configs.yml | ||
| ftr_oblt_stateful_configs.yml | ||
| ftr_platform_stateful_configs.yml | ||
| ftr_search_serverless_configs.yml | ||
| ftr_search_stateful_configs.yml | ||
| ftr_security_serverless_configs.yml | ||
| ftr_security_stateful_configs.yml | ||
| package-lock.json | ||
| package.json | ||
| pull_requests.json | ||
| README.md | ||
| scout_ci_config.yml | ||
| tsconfig.json | ||
| tsconfig.test.json | ||
Kibana / Buildkite
Directory Structure
hooks- special directory used by Buildkite agents for hookspipeline-utils- Shared TypeScript utils for use in pipeline scriptspipelines- contains pipeline definitionsscripts/common- scripts that getsourced by other scripts to set environment variables or import shared functionsscripts/lifecycle- general scripts for tasks that run before or after individual steps or the entire buildscripts/steps- scripts that define something that will run for a step defined in a pipelinescripts/*- all other scripts are building blocks that make up the tasks in pipelines. They may be run by other scripts, but should not besourced