mirror of
https://github.com/elastic/kibana.git
synced 2025-04-23 17:28:26 -04:00
[Security Solution] Enable Cypress Tests for AI4DSOC effort (#214776)
## 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.
This commit is contained in:
Gloria Hornero
GitHub
parent
66b00f3583
commit
c6b594cfee
9 changed files with 437 additions and 0 deletions
|
|
@ -10,6 +10,7 @@ disabled:
|
|||
- x-pack/test/defend_workflows_cypress/serverless_config.ts
|
||||
- x-pack/test/osquery_cypress/serverless_cli_config.ts
|
||||
- x-pack/test/security_solution_cypress/serverless_config.ts
|
||||
- x-pack/test/security_solution_cypress/ai4dsoc_serverless_config.ts
|
||||
|
||||
# Playwright
|
||||
- x-pack/test/security_solution_playwright/serverless_config.ts
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
steps:
|
||||
- command: .buildkite/scripts/steps/functional/security_serverless_ai4dsoc.sh
|
||||
label: 'Serverless AI4DSOC - Security Solution Cypress Tests'
|
||||
agents:
|
||||
machineType: n2-standard-4
|
||||
preemptible: true
|
||||
depends_on:
|
||||
- build
|
||||
- quick_checks
|
||||
- checks
|
||||
- linting
|
||||
- linting_with_types
|
||||
- check_types
|
||||
- check_oas_snapshot
|
||||
timeout_in_minutes: 60
|
||||
parallelism: 1
|
||||
retry:
|
||||
automatic:
|
||||
- exit_status: '-1'
|
||||
limit: 1
|
||||
|
|
@ -263,6 +263,7 @@ const getPipeline = (filename: string, removeSteps = true) => {
|
|||
pipeline.push(
|
||||
getPipeline('.buildkite/pipelines/pull_request/security_solution/ai_assistant.yml')
|
||||
);
|
||||
pipeline.push(getPipeline('.buildkite/pipelines/pull_request/security_solution/ai4dsoc.yml'));
|
||||
pipeline.push(
|
||||
getPipeline('.buildkite/pipelines/pull_request/security_solution/automatic_import.yml')
|
||||
);
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
#!/usr/bin/env bash
|
||||
|
||||
set -euo pipefail
|
||||
|
||||
source .buildkite/scripts/steps/functional/common.sh
|
||||
|
||||
export JOB=kibana-security-solution-chrome
|
||||
export KIBANA_INSTALL_DIR=${KIBANA_BUILD_LOCATION}
|
||||
|
||||
echo "--- AI4DSOC Cypress Tests on Serverless"
|
||||
|
||||
cd x-pack/test/security_solution_cypress
|
||||
|
||||
set +e
|
||||
BK_ANALYTICS_API_KEY=$(vault_get security-solution-ci sec-sol-cypress-bk-api-key)
|
||||
|
||||
BK_ANALYTICS_API_KEY=$BK_ANALYTICS_API_KEY yarn cypress:ai4dsoc:run:serverless; status=$?; yarn junit:merge || :; exit $status
|
||||
3
.github/CODEOWNERS
vendored
3
.github/CODEOWNERS
vendored
|
|
@ -2223,6 +2223,9 @@ x-pack/test/api_integration/apis/management/index_management/inference_endpoints
|
|||
/x-pack/solutions/security/plugins/security_solution_ess/public/upselling/pages/attack_discovery @elastic/security-generative-ai
|
||||
/x-pack/test/security_solution_cypress/cypress/e2e/automatic_import @elastic/security-scalability
|
||||
|
||||
# AI4DSOC in Security Solution
|
||||
/x-pack/test/security_solution_cypress/cypress/e2e/ai4dsoc @elastic/security-engineering-productivity
|
||||
|
||||
# Security Solution cross teams ownership
|
||||
/x-pack/test/security_solution_cypress/cypress/fixtures @elastic/security-detections-response @elastic/security-threat-hunting
|
||||
/x-pack/test/security_solution_cypress/cypress/helpers @elastic/security-detections-response @elastic/security-threat-hunting
|
||||
|
|
|
|||
|
|
@ -0,0 +1,41 @@
|
|||
/*
|
||||
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
|
||||
* or more contributor license agreements. Licensed under the Elastic License
|
||||
* 2.0; you may not use this file except in compliance with the Elastic License
|
||||
* 2.0.
|
||||
*/
|
||||
|
||||
import { FtrConfigProviderContext } from '@kbn/test';
|
||||
import { SecuritySolutionConfigurableCypressTestRunner } from './runner';
|
||||
|
||||
export default async function ({ readConfigFile }: FtrConfigProviderContext) {
|
||||
const svlSharedConfig = await readConfigFile(
|
||||
require.resolve('@kbn/test-suites-serverless/shared/config.base')
|
||||
);
|
||||
|
||||
return {
|
||||
...svlSharedConfig.getAll(),
|
||||
esTestCluster: {
|
||||
...svlSharedConfig.get('esTestCluster'),
|
||||
serverArgs: [
|
||||
...svlSharedConfig.get('esTestCluster.serverArgs'),
|
||||
// define custom es server here
|
||||
// API Keys is enabled at the top level
|
||||
],
|
||||
},
|
||||
kbnTestServer: {
|
||||
...svlSharedConfig.get('kbnTestServer'),
|
||||
serverArgs: [
|
||||
...svlSharedConfig.get('kbnTestServer.serverArgs'),
|
||||
'--serverless=security',
|
||||
'--xpack.encryptedSavedObjects.encryptionKey="abcdefghijklmnopqrstuvwxyz123456"',
|
||||
`--xpack.securitySolutionServerless.productTypes=${JSON.stringify([
|
||||
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
|
||||
])}`,
|
||||
'--csp.strict=false',
|
||||
'--csp.warnLegacyBrowsers=false',
|
||||
],
|
||||
},
|
||||
testRunner: SecuritySolutionConfigurableCypressTestRunner,
|
||||
};
|
||||
}
|
||||
|
|
@ -0,0 +1,334 @@
|
|||
# Cypress Tests
|
||||
|
||||
The `security_solution/cypress/e2e/ai4dsoc` directory contains functional UI tests that execute using [Cypress](https://www.cypress.io/).
|
||||
|
||||
Currently with Cypress you can develop `functional` tests.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
[**How to add a new Cypress test**](#how-to-add-a-new-cypress-test)
|
||||
|
||||
[**Running the tests**](#running-the-tests)
|
||||
|
||||
[**Enabling Experimental Flags**](#enabling-experimental-flags)
|
||||
|
||||
[**Debugging your test**](#debugging-your-test)
|
||||
|
||||
[**Folder structure**](#folder-structure)
|
||||
|
||||
[**Test data**](#test-data)
|
||||
|
||||
[**Serverless**](#serverless)
|
||||
|
||||
[**Development Best Practices**](#development-best-practices)
|
||||
|
||||
[**Test Artifacts**](#test-artifacts)
|
||||
|
||||
[**Linting**](#linting)
|
||||
|
||||
## How to add a new Cypress test
|
||||
|
||||
Before considering adding a new Cypress tests, please make sure you have added unit and API tests first. Note that, the aim of Cypress
|
||||
is to test that the user interface operates as expected, hence, you should not be using this tool to test REST API or data contracts.
|
||||
|
||||
First take a look to the [**Development Best Practices**](#development-best-practices) section.
|
||||
Then check [**Folder structure**](#folder-structure) section to know where is the best place to put your test, [**Test data**](#test-data) section if you need to create any type
|
||||
of data for your test, [**Running the tests**](#running-the-tests) to know how to execute the tests and [**Debugging your test**](#debugging-your-test) to debug your test if needed.
|
||||
|
||||
Please, before opening a PR with the new test, please make sure that the test fails. If you never see your test fail you don’t know if your test is actually testing the right thing, or testing anything at all.
|
||||
|
||||
Note that we use tags in order to select which tests we want to execute:
|
||||
|
||||
- `@serverless` includes a test in the Serverless test suite for PRs (the so-called first quality gate) and QA environment for the periodic pipeline. You need to explicitly add this tag to any test you want to run in CI for serverless.
|
||||
|
||||
## Running the tests
|
||||
|
||||
### Run them locally
|
||||
When running the tests, FTR is used to spawn both a Kibana instance (http://localhost:5620) and an Elasticsearch instance (http://localhost:9220) with a preloaded minimum set of data (see preceding "Test data" section).
|
||||
|
||||
Run the tests with the following yarn scripts from `x-pack/test/security_solution_cypress`:
|
||||
|
||||
| Script Name | Description |
|
||||
| ----------- | ----------- |
|
||||
| cypress:open:ai4dsoc:serverless | Opens the Cypress UI with all tests in the `e2e/aid4soc` directory. This also runs a mocked serverless environment using the `ai_soc` pruduct line and `search_ai_lake` tier by default. |
|
||||
| cypress:run:ai4dsoc:serverless | Runs all tests tagged as SERVERLESS in the `e2e/ai4dsoc` directory in headless mode using the `ai_soc` pruduct line and `search_ai_lake` tier by default.|
|
||||
|
||||
Please note that the headless mode command do not open the Cypress UI and are typically used in CI/CD environments. The scripts that open the Cypress UI are useful for development and debugging.
|
||||
|
||||
### Enabling experimental flags
|
||||
|
||||
When writing a test that requires an experimental flag enabled, you need to pass an extra configuration to the header of the test:
|
||||
|
||||
```typescript
|
||||
describe(
|
||||
'My Experimental Flag test',
|
||||
{
|
||||
env: {
|
||||
ftrConfig: {
|
||||
kbnServerArgs: [
|
||||
`--xpack.securitySolution.enableExperimental=${JSON.stringify([
|
||||
'MY_EXPERIMENTAL_FLAG',
|
||||
])}`,
|
||||
],
|
||||
},
|
||||
},
|
||||
},
|
||||
// ...
|
||||
);
|
||||
```
|
||||
|
||||
Note that this configuration doesn't work for local test development as well as MKI test execution. For local testing and deugginb, you need to update the configuration file: `../ai4dsoc_serverless_config`, but you shouldn't commit these changes.
|
||||
|
||||
## Debugging your test
|
||||
|
||||
In order to be able to debug any Cypress test you need to open Cypress on visual mode. [Here](https://docs.cypress.io/guides/guides/debugging)
|
||||
you can find an extended guide about how to proceed.
|
||||
|
||||
If you are debugging a flaky test, a good tip is to insert a `cy.wait(<some long milliseconds>)` around async parts of the tes code base, such as network calls which can make an indeterministic test, deterministically fail locally.
|
||||
|
||||
## Folder Structure
|
||||
|
||||
Below you can find the folder structure used on our Cypress tests.
|
||||
|
||||
### e2e/
|
||||
|
||||
Cypress convention starting version 10 (previously known as integration). Contains the specs that are going to be executed.
|
||||
|
||||
### AI4DSOC team folder
|
||||
|
||||
All the tests belonging to the AI4DSOC effort should be added to this folder since is the only one that executes the AI4DSOC specific tier by default.
|
||||
|
||||
### fixtures/
|
||||
|
||||
Cypress convention. Fixtures are used as external pieces of static data when we stub responses.
|
||||
|
||||
### plugins/
|
||||
|
||||
Cypress convention. As a convenience, by default Cypress will automatically include the plugins file cypress/plugins/index.js before every single spec file it runs.
|
||||
|
||||
### objects/
|
||||
|
||||
Contains representations of data used across different tests; our domain objects.
|
||||
|
||||
### screens/
|
||||
|
||||
Contains the elements we want to interact with in our tests.
|
||||
|
||||
Each file inside the screens folder represents a screen in our application. When the screens are complex, e.g. Hosts with its multiple tabs, the page is represented by a folder and the different important parts are represented by files.
|
||||
|
||||
Example:
|
||||
|
||||
- screens
|
||||
- hosts
|
||||
- all_hosts.ts
|
||||
- authentications.ts
|
||||
- events.ts
|
||||
- main.ts
|
||||
- uncommon_processes.ts
|
||||
|
||||
### tasks/
|
||||
|
||||
_Tasks_ are functions that may be reused across tests.
|
||||
|
||||
Each file inside the tasks folder represents a screen of our application. When the screens are complex, e.g. Hosts with its multiple tabs, the page is represented by a folder and the different important parts are represented by files.
|
||||
|
||||
Example:
|
||||
|
||||
- tasks
|
||||
- hosts
|
||||
- all_hosts.ts
|
||||
- authentications.ts
|
||||
- events.ts
|
||||
- main.ts
|
||||
- uncommon_processes.ts
|
||||
|
||||
### urls/
|
||||
|
||||
Represents all the URLs used during the tests execution.
|
||||
|
||||
## Test data
|
||||
|
||||
The data the tests need:
|
||||
|
||||
- Is generated on the fly using our application APIs (preferred way)
|
||||
- Is ingested on the ELS instance using the `es_archiver` utility
|
||||
|
||||
By default, when running the tests in Jenkins mode, a base set of data is ingested on the ELS instance: a set of auditbeat data (the `auditbeat` archive). This is usually enough to cover most of the scenarios that we are testing.
|
||||
|
||||
### How to generate a new archive
|
||||
|
||||
**Note:** As mentioned above, archives are only meant to contain external data, e.g. beats data. Due to the tendency for archived domain objects (rules, signals) to quickly become out of date, it is strongly suggested that you generate this data within the test, through interaction with either the UI or the API.
|
||||
|
||||
We use es_archiver to manage the data that our Cypress tests need.
|
||||
|
||||
1. Set up a clean instance of kibana and elasticsearch (if this is not possible, try to clean/minimize the data that you are going to archive).
|
||||
2. With the kibana and elasticsearch instance up and running, create the data that you need for your test.
|
||||
3. When you are sure that you have all the data you need run the following command from: `x-pack/test/security_solution_cypress`
|
||||
|
||||
```sh
|
||||
node ../../../scripts/es_archiver save <nameOfTheFolderWhereDataIsSaved> <indexPatternsToBeSaved> --dir ../../test/security_solution_cypress/es_archives --config ../../../src/platform/test/functional/config.base.js --es-url http://<elasticsearchUsername>:<elasticsearchPassword>@<elasticsearchHost>:<elasticsearchPort>
|
||||
```
|
||||
|
||||
Example:
|
||||
|
||||
```sh
|
||||
node ../../../scripts/es_archiver save custom_rules ".kibana",".siem-signal*" --dir ../../test/security_solution_cypress/es_archives --config ../../../src/platform/test/functional/config.base.js --es-url http://elastic:changeme@localhost:9220
|
||||
```
|
||||
|
||||
Note that the command will create the folder if it does not exist.
|
||||
|
||||
### Using an archive from within the Cypress tests
|
||||
|
||||
Task [cypress/support/es_archiver.ts](https://github.com/elastic/kibana/blob/main/x-pack/test/security_solution_cypress/cypress/support/es_archiver.ts) provides helpers such as `esArchiverLoad` and `esArchiverUnload` by means of `es_archiver`'s CLI.
|
||||
|
||||
Archives used only for Cypress tests purposes are stored in `x-pack/test/security_solution_cypress/es_archives` and are used as follow on the tests.
|
||||
|
||||
```typescript
|
||||
cy.task('esArchiverLoad', { archiveName: 'overview' });
|
||||
cy.task('esArchiverUnload', { archiveName: 'overview'});
|
||||
|
||||
```
|
||||
|
||||
You can also use archives located in `x-pack/test/functional/es_archives/security_solution` by specifying `type: 'ftr'` in the archiver tasks:
|
||||
|
||||
```typescript
|
||||
// loads then unloads from x-pack/test/functional/es_archives/security_solution/alias
|
||||
cy.task('esArchiverLoad', { archiveName: 'alias', type: 'ftr'});
|
||||
cy.task('esArchiverUnload', { archiveName: 'alias', type:'ftr'});
|
||||
```
|
||||
|
||||
## Serverless
|
||||
|
||||
Note that we use tags in order to select which tests we want to execute in the different pipelines, AI4DSOC should have the following labels:
|
||||
|
||||
`@serverless` as mandatory label.
|
||||
`@serverlessQA` for the tests that we want to execute as part of the Kibana QA quality gate.
|
||||
|
||||
#### PLIs
|
||||
When running AI4DSOC Cypress tests, the following PLI is set by default:
|
||||
|
||||
```
|
||||
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' }
|
||||
```
|
||||
|
||||
#### Custom Roles
|
||||
|
||||
Custom roles for serverless is currently supported only for stateless environments (non MKI environments).
|
||||
|
||||
##### Creating a Custom Role
|
||||
|
||||
To create a custom role, use the Cypress task `createServerlessCustomRole`. This task requires two parameters:
|
||||
- **`roleDescriptor`**: Defines the permissions and access for the role.
|
||||
- **`roleName`**: A unique name for the custom role.
|
||||
|
||||
Example:
|
||||
|
||||
```typescript
|
||||
const roleDescriptor = {
|
||||
elasticsearch: {
|
||||
cluster: ['monitor'],
|
||||
indices: [{ names: ['*'], privileges: ['read'] }],
|
||||
},
|
||||
kibana: [
|
||||
{
|
||||
base: ['all'],
|
||||
feature: {},
|
||||
spaces: ['*'],
|
||||
},
|
||||
],
|
||||
};
|
||||
|
||||
cy.task('createServerlessCustomRole', { roleDescriptor, roleName: 'customRole' });
|
||||
```
|
||||
|
||||
##### Using a Custom Role
|
||||
|
||||
Once the custom role is created, you can log in to the application using your regular `login`` method and passing the name of the role.
|
||||
|
||||
```typescript
|
||||
login('customRole');
|
||||
```
|
||||
|
||||
|
||||
##### Deleting a Custom Role
|
||||
|
||||
After your tests, always delete the custom role to ensure a clean environment. Use the `deleteServerlessCustomRole` task and provide the name of the role as the parameter.
|
||||
|
||||
```typescript
|
||||
cy.task('deleteServerlessCustomRole', 'customRole');
|
||||
```
|
||||
|
||||
##### Full workflow
|
||||
|
||||
Here’s the complete workflow for creating, using, and deleting a custom role:
|
||||
|
||||
```typescript
|
||||
const roleDescriptor = {
|
||||
elasticsearch: {
|
||||
cluster: ['monitor'],
|
||||
indices: [{ names: ['*'], privileges: ['read'] }],
|
||||
},
|
||||
kibana: [
|
||||
{
|
||||
base: ['all'],
|
||||
feature: {},
|
||||
spaces: ['*'],
|
||||
},
|
||||
],
|
||||
};
|
||||
|
||||
before(() => {
|
||||
cy.task('createServerlessCustomRole', { roleDescriptor, roleName: 'customRole' });
|
||||
});
|
||||
|
||||
beforeEach(() => {
|
||||
login('customRole');
|
||||
});
|
||||
|
||||
after(() => {
|
||||
cy.task('deleteServerlessCustomRole', 'customRole');
|
||||
});
|
||||
```
|
||||
|
||||
## Development Best Practices
|
||||
|
||||
Below you will a set of best practices that should be followed when writing Cypress tests.
|
||||
|
||||
### Avoid forced actions
|
||||
|
||||
Cypress action commands like `click()`, `type()` and etc allow to pass `force` flag which is set to `false` by default. Avoid passing the `force` flag as it leads to swallowing some UI bugs. If it's impossible to perform an action without forcing it make sure to add an explanation comment and create a ticket to don't forget to fix it later on. The same is applicable to adding an extra `click()` before `type()` command. `type()` clicks an input once and types after so an extra `click()` usually means there is a problem.
|
||||
|
||||
### Write easy to maintain tests
|
||||
|
||||
Consider to extract all the elements you need to interact with to the `screens` folder. In this way in case the locator changes, we just need to update the value in one place.
|
||||
|
||||
### Write easy to read tests
|
||||
|
||||
Consider to extract all the tasks a user should perfom into the `tasks` folder. In this way is going to be easier to undertsand what are we trying to mimic from the user perspective. Also in case there is change on the way the user has to perform the action, we just need to update the value in one place.
|
||||
|
||||
### Make sure your test fails
|
||||
|
||||
Before open a PR with a new test, please first make sure that the test fails. If you never see your test fail you don’t know if your test is actually testing the right thing, or testing anything at all.
|
||||
|
||||
### Minimize the use of es_archive
|
||||
|
||||
When possible, create all the data that you need for executing the tests using the application APIS or the UI.
|
||||
|
||||
## Test Artifacts
|
||||
|
||||
When Cypress tests are run headless on the command line, artifacts
|
||||
are generated under the `target` directory in the root of Kibana as follows:
|
||||
|
||||
- HTML Reports
|
||||
- location: `target/kibana-security-solution/cypress/results/output.html`
|
||||
- `junit` Reports
|
||||
- location: `target/kibana-security-solution/cypress/results`
|
||||
- Screenshots (of failed tests)
|
||||
- location: `target/kibana-security-solution/cypress/screenshots`
|
||||
- Videos
|
||||
- disabled by default, can be enabled by setting env var `CYPRESS_video=true`
|
||||
- location: `target/kibana-security-solution/cypress/videos`
|
||||
|
||||
## Linting
|
||||
|
||||
Optional linting rules for Cypress and linting setup can be found [here](https://github.com/cypress-io/eslint-plugin-cypress#usage)
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
/*
|
||||
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
|
||||
* or more contributor license agreements. Licensed under the Elastic License
|
||||
* 2.0; you may not use this file except in compliance with the Elastic License
|
||||
* 2.0.
|
||||
*/
|
||||
|
||||
import { login } from '../../../tasks/login';
|
||||
import { visit } from '../../../tasks/navigation';
|
||||
import { GET_STARTED_URL } from '../../../urls/navigation';
|
||||
|
||||
describe('Dummy Test ', { tags: '@serverless' }, () => {
|
||||
beforeEach(() => {
|
||||
login();
|
||||
visit(GET_STARTED_URL);
|
||||
});
|
||||
});
|
||||
|
|
@ -25,15 +25,18 @@
|
|||
"junit:merge": "../../../node_modules/.bin/mochawesome-merge ../../../target/kibana-security-solution/cypress/results/mochawesome*.json > ../../../target/kibana-security-solution/cypress/results/output.json && ../../../node_modules/.bin/marge ../../../target/kibana-security-solution/cypress/results/output.json --reportDir ../../../target/kibana-security-solution/cypress/results && yarn junit:transform && mkdir -p ../../../target/junit && cp ../../../target/kibana-security-solution/cypress/results/*.xml ../../../target/junit/",
|
||||
"junit:transform": "node ../../solutions/security/plugins/security_solution/scripts/junit_transformer --pathPattern '../../../target/kibana-security-solution/cypress/results/*.xml' --rootDirectory ../../../ --reportName 'Security Solution Cypress' --writeInPlace",
|
||||
"cypress:serverless": "TZ=UTC node ../../solutions/security/plugins/security_solution/scripts/start_cypress_parallel --config-file ../../test/security_solution_cypress/cypress/cypress_ci_serverless.config.ts --ftr-config-file ../../test/security_solution_cypress/serverless_config",
|
||||
"cypress:ai4dsoc:serverless": "TZ=UTC node ../../solutions/security/plugins/security_solution/scripts/start_cypress_parallel --config-file ../../test/security_solution_cypress/cypress/cypress_ci_serverless.config.ts --ftr-config-file ../../test/security_solution_cypress/ai4dsoc_serverless_config",
|
||||
"cypress:cloud:serverless": "TZ=UTC NODE_TLS_REJECT_UNAUTHORIZED=0 ../../../node_modules/.bin/cypress",
|
||||
"cypress:open:cloud:serverless": "yarn cypress:cloud:serverless open --config-file ./cypress/cypress_serverless.config.ts --env CLOUD_SERVERLESS=true",
|
||||
"cypress:open:serverless": "yarn cypress:serverless open --config-file ../../test/security_solution_cypress/cypress/cypress_serverless.config.ts --spec './cypress/e2e/**/*.cy.ts'",
|
||||
"cypress:open:ai4dsoc:serverless": "yarn cypress:ai4dsoc:serverless open --config-file ../../test/security_solution_cypress/cypress/cypress_serverless.config.ts --spec './cypress/e2e/ai4dsoc/**/*.cy.ts'",
|
||||
"cypress:entity_analytics:run:serverless": "yarn cypress:serverless --spec './cypress/e2e/entity_analytics/**/*.cy.ts'",
|
||||
"cypress:rule_management:run:serverless": "yarn cypress:serverless --spec './cypress/e2e/detection_response/rule_management/!(prebuilt_rules)/**/*.cy.ts'",
|
||||
"cypress:rule_management:prebuilt_rules:run:serverless": "yarn cypress:serverless --spec './cypress/e2e/detection_response/rule_management/prebuilt_rules/**/*.cy.ts'",
|
||||
"cypress:detection_engine:run:serverless": "yarn cypress:serverless --spec './cypress/e2e/detection_response/detection_engine/!(exceptions)/**/*.cy.ts'",
|
||||
"cypress:detection_engine:exceptions:run:serverless": "yarn cypress:serverless --spec './cypress/e2e/detection_response/detection_engine/exceptions/**/*.cy.ts'",
|
||||
"cypress:ai_assistant:run:serverless": "yarn cypress:serverless --spec './cypress/e2e/ai_assistant/**/*.cy.ts'",
|
||||
"cypress:ai4dsoc:run:serverless": "yarn cypress:ai4dsoc:serverless --spec './cypress/e2e/ai4dsoc/**/*.cy.ts'",
|
||||
"cypress:automatic_import:run:serverless": "yarn cypress:serverless --spec './cypress/e2e/automatic_import/**/*.cy.ts'",
|
||||
"cypress:investigations:run:serverless": "yarn cypress:serverless --spec './cypress/e2e/investigations/**/*.cy.ts'",
|
||||
"cypress:explore:run:serverless": "yarn cypress:serverless --spec './cypress/e2e/explore/**/*.cy.ts'",
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue