-
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][Detections]Fixes Rule Management Cypress Tests #96505
Conversation
Pinging @elastic/security-solution (Team: SecuritySolution) |
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
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.
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.
LGTM
@@ -191,7 +191,10 @@ export const resetAllRulesIdleModalTimeout = () => { | |||
|
|||
export const changeRowsPerPageTo = (rowsCount: number) => { | |||
cy.get(PAGINATION_POPOVER_BTN).click({ force: true }); | |||
cy.get(rowsPerPageSelector(rowsCount)).click(); | |||
cy.get(rowsPerPageSelector(rowsCount)) |
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.
Click until we see the desired effect, the effect here being "element is not visible," indicating that the click was received and thus the popover was hidden.
In this way, we avoid the issue at hand, where we were trying to click an element as it was animated/redrawing. 👍
💛 Build succeeded, but was flaky
Test FailuresKibana Pipeline / general / Closes and opens alerts.Closing alerts Closes and opens alertsStack Trace
Metrics [docs]
History
To update your PR or re-run it, just comment with: cc @spong |
…lastic#96505) ## Summary Fixes two cypress tests: > Deleting prebuilt rules "before each" hook for "Does not allow to delete one rule when more than one is selected" elastic#68607 This one is more of a drive around the pot-hole fix as we were waiting for the Alerts Table to load when we really didn't need to. Removed unnecessary check. <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/113932347-b9ab9480-97b0-11eb-8e07-5f3e0c4b6c78.png" /> </p> > Alerts rules, prebuilt rules Loads prebuilt rules elastic#71300 This one was fixed with a `.pipe()` and `.should('not.be.visible')` to ensure the click was successful. Also removed unnecessary check on the Alerts Table loading that was present here as well too.. <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/113932285-ac8ea580-97b0-11eb-90e1-618c510d33a7.png" /> </p>
May've regressed this one... 👀
|
Passing locally, though upon further inspection, this test is definitely going to be flakey as it's checking counts on alerts as they move through different states and there are new alerts that keep coming in (hence the count mis-match in the above failure). Potential fixes would be to use an absolute daterange to after the first round of alerts were generated, or just stop generating alerts before performing the alert state changes. edit: PR here #96523 |
…96505) (#96521) ## Summary Fixes two cypress tests: > Deleting prebuilt rules "before each" hook for "Does not allow to delete one rule when more than one is selected" #68607 This one is more of a drive around the pot-hole fix as we were waiting for the Alerts Table to load when we really didn't need to. Removed unnecessary check. <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/113932347-b9ab9480-97b0-11eb-8e07-5f3e0c4b6c78.png" /> </p> > Alerts rules, prebuilt rules Loads prebuilt rules #71300 This one was fixed with a `.pipe()` and `.should('not.be.visible')` to ensure the click was successful. Also removed unnecessary check on the Alerts Table loading that was present here as well too.. <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/113932285-ac8ea580-97b0-11eb-90e1-618c510d33a7.png" /> </p> Co-authored-by: Garrett Spong <spong@users.noreply.github.com>
…6523) ## Summary As identified in #96505 (comment), this fixes the flakiness in the `Closing alerts` cypress test. Method used was to just delete the rule after the initial batch of alerts were generated. Alternatively we could add a function for disabling the rule (didn't see one in there), but the outcome is the same, no more alerts generated while the test is being performed. 🙂 > Passing locally, though upon further inspection, this test is definitely going to be flakey as it's checking counts on alerts as they move through different states and there are new alerts that keep coming in (hence the count mis-match in the above failure). Potential fixes would be to use an absolute daterange to after the first round of alerts were generated, or just stop generating alerts before performing the alert state changes. ##### Before: <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/113952824-ae1d9500-97d3-11eb-9021-6737544b9c50.png" /> </p> ##### After: <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/113958216-ed50e380-97dd-11eb-9d22-d1c6aafc97d2.png" /> </p>
…astic#96523) ## Summary As identified in elastic#96505 (comment), this fixes the flakiness in the `Closing alerts` cypress test. Method used was to just delete the rule after the initial batch of alerts were generated. Alternatively we could add a function for disabling the rule (didn't see one in there), but the outcome is the same, no more alerts generated while the test is being performed. 🙂 > Passing locally, though upon further inspection, this test is definitely going to be flakey as it's checking counts on alerts as they move through different states and there are new alerts that keep coming in (hence the count mis-match in the above failure). Potential fixes would be to use an absolute daterange to after the first round of alerts were generated, or just stop generating alerts before performing the alert state changes. ##### Before: <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/113952824-ae1d9500-97d3-11eb-9021-6737544b9c50.png" /> </p> ##### After: <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/113958216-ed50e380-97dd-11eb-9d22-d1c6aafc97d2.png" /> </p>
…6523) (#96526) ## Summary As identified in #96505 (comment), this fixes the flakiness in the `Closing alerts` cypress test. Method used was to just delete the rule after the initial batch of alerts were generated. Alternatively we could add a function for disabling the rule (didn't see one in there), but the outcome is the same, no more alerts generated while the test is being performed. 🙂 > Passing locally, though upon further inspection, this test is definitely going to be flakey as it's checking counts on alerts as they move through different states and there are new alerts that keep coming in (hence the count mis-match in the above failure). Potential fixes would be to use an absolute daterange to after the first round of alerts were generated, or just stop generating alerts before performing the alert state changes. ##### Before: <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/113952824-ae1d9500-97d3-11eb-9021-6737544b9c50.png" /> </p> ##### After: <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/113958216-ed50e380-97dd-11eb-9d22-d1c6aafc97d2.png" /> </p> Co-authored-by: Garrett Spong <spong@users.noreply.github.com>
Summary
Fixes two cypress tests:
This one is more of a drive around the pot-hole fix as we were waiting for the Alerts Table to load when we really didn't need to. Removed unnecessary check.
This one was fixed with a
.pipe()
and.should('not.be.visible')
to ensure the click was successful. Also removed unnecessary check on the Alerts Table loading that was present here as well too..