[Security Solution] Exceptions Cypress tests

[MadameSheema]

Summary

In this PR we are adding some tests in order to check that exceptions feature is working fine.

These tests were complex to develop so I will appreciate a deep look to it, because I'm afraid I can be messing or not properly checking things.

For these tests we have created different archives:

• rule_for_exceptions
• rule_for_exceptions_from_alert
• auditbeat_for_exceptions
• auditbeat_for_exceptions2
• auditbeat_for_exceptions3
• auditbeat_for_exceptions_from_alert
• auditbeat_for_exceptions_from_alert2
• auditbeat_for_exceptions_from_alert3

The rule_for_exceptions archive contains a custom rule with query host.name:* and index pattern exceptions-*. As on CI all the Kibana tests are executed in parallel, this was the selected index pattern in order to avoid collisions with different tests from different teams using a common index pattern (i.e. auditbeat).

The rule_for_exceptions_from_alert archive contains a rule with archive contains a custom rule with query host.name:* and index pattern exceptionsalert-*. This index pattern was selected from the same reason as the previous one and also, to prevent collisions with the previous test.

auditbeat_for_exceptions, auditbeat_for_exceptions2 and auditbeat_for_exceptions3, each archive contains 2 different alerts that matches the exceptions-* pattern.

auditbeat_for_exceptions_from_alert, auditbeat_for_exceptions_from_alert2, auditbeat_for_exceptions_from_alert3, each archive contains 2 different alerts that thames the exceptionsalert-* pattern.

Creates an exception from rule details and deletes the exception implementation:

• We load the rule
• We activate it
• We load the first set of data
• We wait for the rule to be executed
• We deactivate the rule
• We check that the rule has populated the expected alerts
• We add an exception from the rule details for all the host.names that matches with the alerts on the archive, checking the closing alerts option
• We activate the rule again
• We load a new set of data
• We wait for the rule to be executed again
• We navigate to closed alerts in order to check that the alerts have been closed
• We navigate to opened alerts and we check that no new rules have been populated
• We delete the exception
• We load a new set of data
• We wait for the rule to be executed
• We check that the rule has populated the expected alerts

Creates an exception from an existing alert and deletes the exception implementation:

• We load the rule
• We activate it
• We load the first set of data
• We wait for the rule to be executed
• We deactivate the rule
• We check that the rule has populated the expected alerts
• We add an exception from the first existing alert for all the host.names that matches with the alerts on the archive, checking the closing alerts option
• We activate the rule again
• We load a new set of data
• We wait for the rule to be executed again
• We navigate to closed alerts in order to check that the alerts have been closed
• We navigate to opened alerts and we check that no new rules have been populated
• We delete the exception
• We load a new set of data
• We wait for the rule to be executed
• We check that the rule has populated the expected alerts

[MadameSheema]

@elasticmachine merge upstream

[peluja1012]

LGTM. Thanks for added coverage and for helping debug the "conflict" issue!

[patrykkopycinski]

@elasticmachine merge upstream

[MadameSheema]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 6f57aae

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	8.0MB	8.0MB	+159.0B

Distributable file count

id	before	after	diff
default	43134	43139	+5

History

• 💚 Build #90552 succeeded ee2a570
• 💚 Build #90548 succeeded 661cd54
• 💚 Build #90540 succeeded 9fc8984
• 💔 Build #90534 failed df1b01e
• 💔 Build #90527 failed a32a240

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream