-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Security Solution] Removes esArchiverResetKibana
from our Cypress tests
#169563
[Security Solution] Removes esArchiverResetKibana
from our Cypress tests
#169563
Conversation
esArchiverResetKibana
from our Cypress tests
Pinging @elastic/security-solution (Team: SecuritySolution) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Threat Hunting changes lgtm 🎉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Detection Engine area LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MadameSheema thank you for addressing MKI related issues in the tests 🙏
The approach looks good to me but some details require clarification so I left comments.
} from '../../../../tasks/prebuilt_rules'; | ||
import { visitRulesManagementTable } from '../../../../tasks/rules_management'; | ||
|
||
describe.skip( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this test suite is skipped?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I splitted prebuilt_rules_install_update_workflows.cy.ts
in different spec files like this one, at some point my PR started to fail and I saw that was skipped in main, so I skipped this test as was part of the original skipped spec file.
Now that the issue as been addressed I'll make sure it us unskipped and all the changes made are reflected as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jpdjere Could you please review the changes to tests for prebuilt rules in this PR?
import { addElasticRulesButtonClick } from '../../../../tasks/prebuilt_rules'; | ||
import { visitRulesManagementTable } from '../../../../tasks/rules_management'; | ||
|
||
describe.skip( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this test suite is skipped?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I splitted prebuilt_rules_install_update_workflows.cy.ts
in different spec files like this one, at some point my PR started to fail and I saw that was skipped in main, so I skipped this test as was part of the original skipped spec file.
Now that the issue as been addressed I'll make sure it us unskipped and all the changes made are reflected as well.
} from '../../../../tasks/prebuilt_rules'; | ||
import { visitRulesManagementTable } from '../../../../tasks/rules_management'; | ||
|
||
describe.skip( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this test suite is skipped?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I splitted prebuilt_rules_install_update_workflows.cy.ts
in different spec files like this one, at some point my PR started to fail and I saw that was skipped in main, so I skipped this test as was part of the original skipped spec file.
Now that the issue as been addressed I'll make sure it us unskipped and all the changes made are reflected as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Maybe rename file to install_via_fleet.cy.ts
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Maybe rename to install_workflow
? We could reduce occurrences of prebuilt_rules
in the path to make it shorter but it still will be clear what group these tests belong.
I'd also move prebuilt rules tests one directory up to remove prebuilt_rules_install_update_workflows
folder. So we'd have all prebuilt rules test suites under prebuilt_rules
folder.
@@ -132,6 +127,10 @@ describe( | |||
]); | |||
}); | |||
|
|||
afterEach(() => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's delete data view in before each.
@@ -46,13 +46,12 @@ describe( | |||
{ tags: ['@ess', '@serverless', '@skipInServerless'] }, | |||
() => { | |||
beforeEach(() => { | |||
cy.task('esArchiverResetKibana'); | |||
login(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting that login()
isn't required to be done before ES data manipulation helpers as rootRequest()
helper under the hood uses ELASTICSEARCH_USERNAME
and ELASTICSEARCH_PASSWORD
for auth.
@@ -19,15 +19,23 @@ export const createEndpointExceptionList = () => | |||
rootRequest<ExceptionListSchema>({ | |||
method: 'POST', | |||
url: ENDPOINT_LIST_URL, | |||
headers: { 'kbn-xsrf': 'cypress-creds', 'x-elastic-internal-origin': 'security-solution' }, | |||
headers: { | |||
'kbn-xsrf': 'cypress-creds', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rootRequet
already has this header. Ideally 'x-elastic-internal-origin': 'security-solution'
should be inside rootRequest
as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@maximpn I see that this is a broader problem across other API calls referencing rootRequest
. It is if the cleanup is done in a follow-up PR?
@@ -183,6 +185,12 @@ export const validateEmptyExceptionConditionField = () => { | |||
}; | |||
export const submitNewExceptionItem = () => { | |||
cy.get(CONFIRM_BTN).should('exist'); | |||
cy.root().then(($page) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why was it added?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When doing some pair programming and testing with @WafaaNasr to check which indices we should delete for the exceptions-specific tests, sometimes we saw displayed an unrelated toaster error message unrelated with the testing we were performing. That toaster was blocking the confirm button we had to click, using force true would solve the issue, but I'm against the use of it.
If you check the current code on tasks/exceptions_table.ts
, there are some tests that use the closeErrorToast()
method to close error toasters before continuing with the interactions with the page. That is why I decided to add a smaller piece of code that checks if a toaster is displayed and if so, close it to continue with the test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MadameSheema thank you for the explanation. Did I get it right the toaster doesn't always appear? May it's some UI related issue.
Could you add a comment in. the code to clarify your changes?
@MadameSheema Thank you for taking care of splitting tests for prebuilt rules into multiple files, the one we had got too big already. @jpdjere Please review these changes since you're the main author and the owner of these tests. @MadameSheema Once all the adjustments are done in this PR, before merging it, please run the changed tests in the flaky test runner in both ESS and Serverless. @jpdjere and @maximpn have been doing this for all their PRs for tests for the last several weeks and it's a good way to make sure PRs don't introduce new flakes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To keep consistency with install_workflow
let's rename this file to update_workflow
, as they were both two subsections of the same test suite.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the splitting up of the /prebuilt_rules
dir. Left only one comment to rename a file for consistency.
@elasticmachine merge upstream |
150 executions for the tests inside the exceptions folder and all passed :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MadameSheema thank you addressing the comments 👍
150 executions for the tests inside the detections_response folders. The only test failing is a known flaky test and is unrelated to the changes I introduced, so if after merging with main al the tests continue passing, I'll merge the changes. Thanks!! :) |
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
## Summary After the merge of #169563 seems that there is a test still using resetKibana (I don't know the reason). In this PR we are fixing that. Execution in ESS: <img width="2560" alt="Screenshot 2023-10-31 at 12 46 55" src="https://github.com/elastic/kibana/assets/17427073/dc14eb9a-9ef5-4c35-be83-9f76d9812f8e"> Execution in Serverless: <img width="2552" alt="Screenshot 2023-10-31 at 12 49 14" src="https://github.com/elastic/kibana/assets/17427073/28594862-1c0d-40f5-9b9e-dfe7f97584cc">
## Summary After the merge of elastic#169563 seems that there is a test still using resetKibana (I don't know the reason). In this PR we are fixing that. Execution in ESS: <img width="2560" alt="Screenshot 2023-10-31 at 12 46 55" src="https://github.com/elastic/kibana/assets/17427073/dc14eb9a-9ef5-4c35-be83-9f76d9812f8e"> Execution in Serverless: <img width="2552" alt="Screenshot 2023-10-31 at 12 49 14" src="https://github.com/elastic/kibana/assets/17427073/28594862-1c0d-40f5-9b9e-dfe7f97584cc">
Context
We are working to execute our Cypress tests in the second Quality Gate (QA environment, deployed projects on MKI). To do so we are mimicking the orchestration we currently have thanks to the
parallel.ts
script on our ESS and serverless FTR environment, where each spec file is executed in its own project and each spec file can set the PLI that needs to be executed.While testing the changes, we saw the following error when
esArchiverResetKibana
was executed:This is because in a real serverless environment, it is not allowed to access restricted / system indices directly and
esArchiverResetKibana
is deleting a bunch of those.In this PR
In this PR we are getting rid of
esArchiverResetKibana
method, in order to do so, we are following different strategies depending on the requirements of the tests:(1) Removing the method directly from the test. This is because each spec file is executed in a clean instance and there is no need to remove/clean anything between tests.
(2) Cleaning just the indices that are modified during the spec execution and may impact other tests inside the same spec.
(3) Different approach.
Approaches followed for each test:
detection_response/detection_alerts/alert_tags.cy.ts
detection_response/prebuilt_rules_install_update_workflows.cy.ts
detection_response/rule_creation/custom_query_rule_data_view.cy.ts
ddetection_response/rule_management/rule_actions/bulk_actions/bulk_duplicate_rules.cy.ts
detection_response/rule_management/rule_actions/bulk_actions/bulk_edit_rules.cy.ts
detection_response/rule_management/rule_actions/bulk_actions/bulk_edit_rules_actions.cy.ts
detection_response/rule_management/rule_actions/bulk_actions/bulk_edit_rules_data_view.cy.ts
detection_response/rule_management/rules_table/rules_table_filtering.cy.ts
detection_response/sourcerer/sourcerer.cy.ts
detection_response/sourcerer/sourcerer_permissions.cy.ts
exceptions/alerts_table_flow/endpoint_exceptions.cy.ts
exceptions/entry/flyout_validation.cy.ts
exceptions/entry/multiple_conditions.cy.ts
exceptions/rule_details_flow/add_edit_endpoint_exception.cy.ts
exceptions/rule_details_flow/add_edit_exception.cy.ts
exceptions/rule_details_flow/add_edit_exception_data_view.cy.ts
exceptions/shared_exception_lists_management/list_detail_page/list_details.cy.ts
exceptions/shared_exception_lists_management/manage_exceptions.cy.ts
exceptions/shared_exception_lists_management/manage_exceptions.cy.ts
exceptions/shared_exception_lists_management/filter_table.cy.ts
exceptions/shared_exception_lists_management/import_lists.cy.ts
exceptions/shared_exception_lists_management/manage_lists.cy.ts
exceptions/shared_exception_lists_management/read_only.cy.ts
Things to take into consideration
These changes would help to make most of the above tests pass in MKI environment. We need to take into consideration that some might still fail if we continue accessing restricted indices.
Next steps