[Security Solution] Adds prebuilt rule import/export integration tests #206893
Conversation
dplumlee
added
test
release_note:skip
|
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
|
Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management) |
Also not sure, tbh, but I see that we can pass Kibana configuration options in FTR configs (example). We might try something like |
|
@elasticmachine merge upstream |
There was a problem hiding this comment.
@dplumlee I made some minor adjustments to the test plan in bde4612, just to:
- Fix broken links in the table of contents (looks like it didn't like underscores in
rule_ids) - Clarify some scenarios, make wordings more consistent.
I'm posting more substantial issues with the test plan as comments. I'm gonna open a separate PR that will address these issues.
| #### Scenario: Importing a custom rule with a matching prebuilt `rule_id` and `version` | ||
|
|
||
| **Automation**: 1 cypress test and 1 integration test. | ||
|
|
||
| CASE: Should work with older, newer, or identical version numbers | ||
| ```Gherkin | ||
| Given the import payload contains a custom rule | ||
| And its rule_id and version match a rule asset from the installed package | ||
| When the user imports the rule | ||
| Then the rule should be created or updated | ||
| And the ruleSource type should be "external" | ||
| And isCustomized should be true |
There was a problem hiding this comment.
Thanks for adding this scenario, this is a correct one 👍
| #### Scenario: Importing a custom rule with a matching custom `rule_id` and `version` | ||
|
|
||
| **Automation**: 1 cypress test and 1 integration test. | ||
|
|
||
| ```Gherkin | ||
| Given the import payload contains a custom rule with a matching rule_id and version | ||
| Given the import payload contains a custom rule | ||
| And its rule_id and version match a rule asset from the installed package | ||
| And the overwrite flag is set to true | ||
| When the user imports the rule | ||
| Then the rule should be updated | ||
| Then the rule should be created or updated | ||
| And the ruleSource type should be "internal" | ||
| ``` |
There was a problem hiding this comment.
This scenario doesn't make sense to me, but maybe I'm just not sure what we're testing here.
For determining if a rule that's being imported, if it's a prebuilt or a custom rule, it only matters if its rule_id matches any of the installed rule assets. It doesn't matter what rule_id does an existing custom rule have. By the way, if there's a custom rule with a rule_id that matches the rule_id of the rule being imported AND there's also a matching rule assets, this rule should be updated and converted to a prebuilt rule. And it doesn't look like we have this scenario in the test plan.
I'd suggest we:
- Remove this scenario.
- Extract scenarios for custom rules and for common importing logic to a separate test plan.
- Add more scenarios for various edge cases.
I can address this in a separate PR.
| When the user imports the rule | ||
| Then the rule should be created | ||
| Then the rule should be created or updated |
There was a problem hiding this comment.
We should have separate, more specific scenarios for each scenario that says should be created or updated. This assumes different test setups and can't be covered by a single integration test.
| And the rule should be created or updated | ||
| And the ruleSource type should be "external" |
There was a problem hiding this comment.
In this test plan, we use a lot of technical terminology that is obscure to anyone otside of our team and can become obsolete at some point.
I'd suggest to replace it with a more user-friendly terminology:
- "rule source type is external" to "prebuilt rule"
- "rule source type is internal" to "custom rule"
- "isCustomized is true" to "marked as customized"
- etc
I will address this in a separate PR.
There was a problem hiding this comment.
I'm missing UI-focused scenarios, I think we should have some that would cover some user stories added to the test plan. Again, will do in a separate PR.
| When the user imports the rule | ||
| Then the rule should be created | ||
| And the ruleSource type should be "internal" | ||
| And the "version" field should be set to 1 | ||
| ``` | ||
|
|
||
| #### Scenario: Importing a rule with overwrite flag set to true | ||
| #### Scenario: Importing a rule with `overwrite` flag set to true |
There was a problem hiding this comment.
The two scenarios for the overwrite flag are not related to the logic of importing prebuilt rules. This is a common logic for importing any rules. Let's extract these into a separate test plan.
We could just add And the overwrite flag is set to true to most of the scenarios in this plan.
@nikitaindik @dplumlee I appreciate the attention to detail here but this test plan and test coverage should be focused only on prebuilt rules. Testing any common importing and exporting logic is out of the scope - there's a lot to cover there and we don't have the resources for that at the moment. |
There was a problem hiding this comment.
@dplumlee Posting some final comments. To summarize:
- The test plan and integration tests look good, but they are not comprehensive and should be extended and improved. I can help you with that and open a follow-up PR that would address the comments I left - most of them are FYI.
- In this PR, I'm only asking to:
- Skip the integration test that tests the package installation inside of the import endpoint.
- Extract all the changes to Cypress tests to a separate PR.
Approving in advance.
| @@ -59,8 +66,38 @@ export default ({ getService }: FtrProviderContext): void => { | |||
| }); | |||
|
|
|||
| describe('calculation of rule customization fields', () => { | |||
| it('defaults a versionless custom rule to "version: 1"', async () => { | |||
| const rule = getCustomQueryRuleParams({ rule_id: 'custom-rule', version: undefined }); | |||
| it('imports a rule with overwrite flag set to true', async () => { | |||
There was a problem hiding this comment.
it('imports a rule with overwrite flag set to true'
it('rejects a rule with an existing rule_id when overwrite flag set to false'
As already commented in the test plan, I think these should be tested as part of some overall tests for rule import, and not for importing prebuilt rules. As at this point we don't have another place where the feature flag would be enabled, I think it's ok to keep these tests in this file. But I'd suggest to move them outside of the calculation of rule customization fields describe block to a separate dedicated block, or to a separate file.
Also, the imports a rule with overwrite flag set to true test doesn't fully match its scenario from the test plan, as we don't check if the rule is being overwritten.
| it('imports a custom rule with a matching prebuilt rule_id and version', async () => { | ||
| const rule = getCustomQueryRuleParams({ | ||
| rule_id: prebuiltRules[0].rule_id, | ||
| version: prebuiltRules[0].version, | ||
| }); |
There was a problem hiding this comment.
imports a custom rule
What makes it custom in the code of the test?
We probably should specify the immutable and rule_source fields in the payload.
There should be another test where this rule should already exist before the import call. Ah, I guess it's the imports a custom rule with a matching custom rule_id and version one!
| it('imports an existing custom rule missing a version field', async () => { | ||
| await securitySolutionApi | ||
| .createRule({ body: getCustomQueryRuleParams({ rule_id: 'custom-rule', version: 23 }) }) | ||
| .expect(200); | ||
|
|
||
| const rule = getCustomQueryRuleParams({ rule_id: 'custom-rule', version: undefined }); | ||
| const { body } = await importRules([rule], true); | ||
|
|
||
| expect(body).toMatchObject({ | ||
| rules_count: 1, | ||
| success: true, | ||
| success_count: 1, | ||
| errors: [], | ||
| }); | ||
|
|
||
| const importedRule = await fetchRule(supertest, { ruleId: 'custom-rule' }); | ||
| expect(importedRule).toMatchObject({ | ||
| rule_id: 'custom-rule', | ||
| version: 1, | ||
| rule_source: { type: 'internal' }, | ||
| immutable: false, | ||
| }); | ||
| }); |
There was a problem hiding this comment.
This doesn't fully match the scenario:
Given the import payload contains a custom rule without a version field
And its rule_id does NOT match any rule assets from the installed package
And this custom rule has already been created
When the user imports the rule
Then the rule should be updated
And the ruleSource type should be "internal"
And the "version" field should be set to the existing rule's "version"Then the rule should be updated
This check is missing
And the "version" field should be set to the existing rule's "version"
This seems to not match the scenario. In reality the version gets reset to 1. Probably the scenario should be fixed as it doesn't reflect the behavior that has always been there? Or do we have a regression?
| it('imports a prebuilt rule with a non-existing rule_id', async () => { | ||
| const rule = createRuleAssetSavedObject({ rule_id: 'wacky-rule-id', version: 1234 })[ | ||
| 'security-rule' | ||
| ]; |
There was a problem hiding this comment.
What makes this rule "prebuilt" in the code of the test?
| immutable: false, | ||
| }); | ||
| }); | ||
|
|
||
| it('rejects a versionless prebuilt rule', async () => { |
There was a problem hiding this comment.
Let's keep the wording closer to the test plan:
| it('rejects a versionless prebuilt rule', async () => { | |
| it('rejects a prebuilt rule with a matching rule_id but missing a version field', async () => { |
| }, | ||
| }); | ||
| }); | ||
|
|
||
| it('respects the version of a prebuilt rule', async () => { |
There was a problem hiding this comment.
We're missing a scenario for this test in the test plan.
| expect(body).toMatchObject({ | ||
| rules_count: 1, | ||
| success: true, | ||
| success_count: 1, | ||
| errors: [], | ||
| }); | ||
|
|
||
| const status = await getPrebuiltRulesAndTimelinesStatus(es, supertest); | ||
| expect(status.rules_installed).toEqual(1); // The rule package is now redownloaded and recognizes the rule_id as an installed rule |
There was a problem hiding this comment.
We should have a more elaborate set of assertions to make sure that the rule was imported correctly as a prebuilt rule.
| it('imports prebuilt rules when the rules package is not installed', async () => { | ||
| await deletePrebuiltRulesFleetPackage({ supertest, es, log, retryService }); // First we delete the rule package |
There was a problem hiding this comment.
I'm not sure if this is the correct test setup.
- We don't install the package during the test setup.
- If the package is installed, deleting it causes Fleet to delete all the rule asset saved objects. I don't know if this happens if the package is not actually installed.
- We don't make sure to reinstall the assets. We do it only once in the top-level
beforeblock for the whole file. This breaks isolation between this test and the rest of the tests in this file.
Please skip the test, I'll try to reimplement it.
There was a problem hiding this comment.
I'm missing the following scenarios from the test plan:
- Scenario: Importing a non-customized prebuilt rule with a matching rule_id and version
- Scenario: Importing a customized prebuilt rule with a matching rule_id and version
- Scenario: Importing a prebuilt rule with a matching rule_id but no matching version
The "Scenario: Importing a custom rule before a prebuilt rule asset is created with the same rule_id" is also missing, but that's ok as it can't be automated at the moment.
There was a problem hiding this comment.
Could you please extract changes to Cypress tests from this PR to a separate one?
I'd like us to merge changes to the test plan and integration tests, and then rework and extend them in a follow-up.
Also:
- We should run the integration tests via the flaky test runner in this PR.
- I would prefer us to run the Cypress tests via the Flaky test runner separately, as they are way less reliable.
dplumlee
force-pushed
the
import-export-prebuilt-rule-tests
branch
from
bde4612 to
964292e
Compare
dplumlee
changed the title
banderror
changed the title
|
@elasticmachine merge upstream |
banderror
force-pushed
the
import-export-prebuilt-rule-tests
branch
from
c551a85 to
dfa183e
Compare
💚 Build Succeeded
Metrics [docs]
History
cc @dplumlee |
Flaky Test Runner Stats🎉 All tests passed! - kibana-flaky-test-suite-runner#7921[✅] x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/prebuilt_rules/prebuilt_rule_customization/customization_enabled/configs/ess.config.ts: 100/100 tests passed. |
Flaky Test Runner Stats🎉 All tests passed! - kibana-flaky-test-suite-runner#7922[✅] x-pack/test/security_solution_api_integration/test_suites/detections_response/rules_management/prebuilt_rules/prebuilt_rule_customization/customization_enabled/configs/serverless.config.ts: 100/100 tests passed. |
|
Starting backport for target branches: 8.18, 8.x, 9.0 |
elastic#206893) ## Summary Adds integration tests in accordance to elastic#204889 Adds on to the existing tests we have for rule import and export to include tests related to the prebuilt rule customization epic and the new functionality that will be shipping. All these tests are running behind the `prebuiltRulesCustomizationEnabled` feature flag. ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [x] ESS x100: https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7921 - [x] Serverless x100: https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7922 --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co> (cherry picked from commit 3e4ed6e)
elastic#206893) ## Summary Adds integration tests in accordance to elastic#204889 Adds on to the existing tests we have for rule import and export to include tests related to the prebuilt rule customization epic and the new functionality that will be shipping. All these tests are running behind the `prebuiltRulesCustomizationEnabled` feature flag. ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [x] ESS x100: https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7921 - [x] Serverless x100: https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7922 --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co> (cherry picked from commit 3e4ed6e)
elastic#206893) ## Summary Adds integration tests in accordance to elastic#204889 Adds on to the existing tests we have for rule import and export to include tests related to the prebuilt rule customization epic and the new functionality that will be shipping. All these tests are running behind the `prebuiltRulesCustomizationEnabled` feature flag. ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [x] ESS x100: https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7921 - [x] Serverless x100: https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7922 --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co> (cherry picked from commit 3e4ed6e)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
…n tests (#206893) (#212194) # Backport This will backport the following commits from `main` to `9.0`: - [[Security Solution] Adds prebuilt rule import/export integration tests (#206893)](#206893) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Davis Plumlee","email":"56367316+dplumlee@users.noreply.github.com"},"sourceCommit":{"committedDate":"2025-02-24T01:18:02Z","message":"[Security Solution] Adds prebuilt rule import/export integration tests (#206893)\n\n## Summary\n\nAdds integration tests in accordance to\nhttps://github.com//pull/204889\n\nAdds on to the existing tests we have for rule import and export to\ninclude tests related to the prebuilt rule customization epic and the\nnew functionality that will be shipping. All these tests are running\nbehind the `prebuiltRulesCustomizationEnabled` feature flag.\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [x] [Flaky Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\nused on any tests changed\n- [x] ESS x100:\nhttps://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7921\n- [x] Serverless x100:\nhttps://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7922\n\n---------\n\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>\nCo-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co>","sha":"3e4ed6ebd58c77f555e2eb1287f70ad41ca73666","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["test","release_note:skip","v9.0.0","Team:Detections and Resp","Team: SecuritySolution","Team:Detection Rule Management","Feature:Prebuilt Detection Rules","backport:version","v8.18.0","v9.1.0","v8.19.0"],"title":"[Security Solution] Adds prebuilt rule import/export integration tests","number":206893,"url":"https://github.com/elastic/kibana/pull/206893","mergeCommit":{"message":"[Security Solution] Adds prebuilt rule import/export integration tests (#206893)\n\n## Summary\n\nAdds integration tests in accordance to\nhttps://github.com//pull/204889\n\nAdds on to the existing tests we have for rule import and export to\ninclude tests related to the prebuilt rule customization epic and the\nnew functionality that will be shipping. All these tests are running\nbehind the `prebuiltRulesCustomizationEnabled` feature flag.\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [x] [Flaky Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\nused on any tests changed\n- [x] ESS x100:\nhttps://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7921\n- [x] Serverless x100:\nhttps://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7922\n\n---------\n\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>\nCo-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co>","sha":"3e4ed6ebd58c77f555e2eb1287f70ad41ca73666"}},"sourceBranch":"main","suggestedTargetBranches":["9.0","8.18","8.x"],"targetPullRequestStates":[{"branch":"9.0","label":"v9.0.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.18","label":"v8.18.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/206893","number":206893,"mergeCommit":{"message":"[Security Solution] Adds prebuilt rule import/export integration tests (#206893)\n\n## Summary\n\nAdds integration tests in accordance to\nhttps://github.com//pull/204889\n\nAdds on to the existing tests we have for rule import and export to\ninclude tests related to the prebuilt rule customization epic and the\nnew functionality that will be shipping. All these tests are running\nbehind the `prebuiltRulesCustomizationEnabled` feature flag.\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [x] [Flaky Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\nused on any tests changed\n- [x] ESS x100:\nhttps://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7921\n- [x] Serverless x100:\nhttps://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7922\n\n---------\n\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>\nCo-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co>","sha":"3e4ed6ebd58c77f555e2eb1287f70ad41ca73666"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Davis Plumlee <56367316+dplumlee@users.noreply.github.com>
…on tests (#206893) (#212192) # Backport This will backport the following commits from `main` to `8.18`: - [[Security Solution] Adds prebuilt rule import/export integration tests (#206893)](#206893) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Davis Plumlee","email":"56367316+dplumlee@users.noreply.github.com"},"sourceCommit":{"committedDate":"2025-02-24T01:18:02Z","message":"[Security Solution] Adds prebuilt rule import/export integration tests (#206893)\n\n## Summary\n\nAdds integration tests in accordance to\nhttps://github.com//pull/204889\n\nAdds on to the existing tests we have for rule import and export to\ninclude tests related to the prebuilt rule customization epic and the\nnew functionality that will be shipping. All these tests are running\nbehind the `prebuiltRulesCustomizationEnabled` feature flag.\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [x] [Flaky Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\nused on any tests changed\n- [x] ESS x100:\nhttps://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7921\n- [x] Serverless x100:\nhttps://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7922\n\n---------\n\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>\nCo-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co>","sha":"3e4ed6ebd58c77f555e2eb1287f70ad41ca73666","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["test","release_note:skip","v9.0.0","Team:Detections and Resp","Team: SecuritySolution","Team:Detection Rule Management","Feature:Prebuilt Detection Rules","backport:version","v8.18.0","v9.1.0","v8.19.0"],"title":"[Security Solution] Adds prebuilt rule import/export integration tests","number":206893,"url":"https://github.com/elastic/kibana/pull/206893","mergeCommit":{"message":"[Security Solution] Adds prebuilt rule import/export integration tests (#206893)\n\n## Summary\n\nAdds integration tests in accordance to\nhttps://github.com//pull/204889\n\nAdds on to the existing tests we have for rule import and export to\ninclude tests related to the prebuilt rule customization epic and the\nnew functionality that will be shipping. All these tests are running\nbehind the `prebuiltRulesCustomizationEnabled` feature flag.\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [x] [Flaky Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\nused on any tests changed\n- [x] ESS x100:\nhttps://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7921\n- [x] Serverless x100:\nhttps://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7922\n\n---------\n\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>\nCo-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co>","sha":"3e4ed6ebd58c77f555e2eb1287f70ad41ca73666"}},"sourceBranch":"main","suggestedTargetBranches":["9.0","8.18","8.x"],"targetPullRequestStates":[{"branch":"9.0","label":"v9.0.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.18","label":"v8.18.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/206893","number":206893,"mergeCommit":{"message":"[Security Solution] Adds prebuilt rule import/export integration tests (#206893)\n\n## Summary\n\nAdds integration tests in accordance to\nhttps://github.com//pull/204889\n\nAdds on to the existing tests we have for rule import and export to\ninclude tests related to the prebuilt rule customization epic and the\nnew functionality that will be shipping. All these tests are running\nbehind the `prebuiltRulesCustomizationEnabled` feature flag.\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [x] [Flaky Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\nused on any tests changed\n- [x] ESS x100:\nhttps://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7921\n- [x] Serverless x100:\nhttps://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7922\n\n---------\n\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>\nCo-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co>","sha":"3e4ed6ebd58c77f555e2eb1287f70ad41ca73666"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Davis Plumlee <56367316+dplumlee@users.noreply.github.com>
Summary
Adds integration tests in accordance to #204889
Adds on to the existing tests we have for rule import and export to include tests related to the prebuilt rule customization epic and the new functionality that will be shipping. All these tests are running behind the
prebuiltRulesCustomizationEnabledfeature flag.Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.