-
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
Re-enable and fix APM E2E tests #114831
Re-enable and fix APM E2E tests #114831
Conversation
* Run previously disabled APM E2E tests on all PRs (we were previously only running them when APM files had changes.) * Remove `precise: true` from `getComparisonTypes` call which caused intermittent failures in date comparison tests. * Simplify error count alert tests to test the "happy path" (elastic#79284 exists in order to expand to more tests for rule editing and creation) * Wait for alert list API request to complete before clicking "Create rule" button when running the test to create a rule from the Stack Management UI. I ran the e2e tests 100 times locally with no failures so I'm confident the flakiness has been addressed. Fixes elastic#114419. Fixes elastic#109205.
Pinging @elastic/apm-ui (Team:apm) |
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.
Do we want the buildkite version updated too?
.buildkite/scripts/pipelines/pull_request/pipeline.js
@@ -20,66 +20,55 @@ describe('Rules', () => { | |||
describe('when created from Service Inventory', () => { | |||
before(() => { | |||
cy.loginAsPowerUser(); | |||
cy.deleteAllRules(); |
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.
Do you really need to call this on before
and after?
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.
It works if you don't do this, but it's better to start with a consistent state (that is, no rules present) and clean up afterwards. It's possible a previous test errors and fails to clean up after itself to this ensures that does not impact the results of this 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.
This is also in line with "Cypress Best Practices": https://docs.cypress.io/guides/references/best-practices#Using-after-or-afterEach-hooks
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.
Test changes look good to me.
@elasticmachine merge upstream |
@@ -7,6 +7,22 @@ | |||
import 'cypress-real-events/support'; | |||
import { Interception } from 'cypress/types/net-stubbing'; | |||
|
|||
Cypress.Commands.add('deleteAllRules', () => { |
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.
What about namespacing commands like:
Cypress.Commands.add('deleteAllRules', () => { | |
Cypress.Commands.add('alerting:deleteAllRules', () => { |
I think that will come handy as we add more commands in the future.
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.
Oh, I suppose :
is not supported. But maybe we can find another separator
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 made this a command because it looked like the kind of thing that was expected in Cypress, but after reading https://docs.cypress.io/api/cypress-api/custom-commands#Best-Practices, I might just go back to making it a function in the rules test, since that's the only place it's used.
/^x-pack\/plugins\/security_solution/, | ||
/^x-pack\/test\/security_solution_cypress/, | ||
/^x-pack\/plugins\/triggers_actions_ui\/public\/application\/sections\/action_connector_form/, | ||
/^x-pack\/plugins\/triggers_actions_ui\/public\/application\/context\/actions_connectors_context\.tsx/, | ||
]) || process.env.GITHUB_PR_LABELS.includes('ci:all-cypress-suites') |
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 think this change is from Prettier.
💚 Build Succeeded
Metrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
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.
@smith it looks like when this week
is selected both options show up, while it should only show week before
.
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, but we should fix the comparison bug on another PR.
Thanks @cauemarcondes. I opened #115247. |
* Re-enable previously disabled APM E2E tests. * Round to the nearest second in `getComparisonTypes` to avoid cases where a millisecond difference can change which results get shown. * Simplify error count alert tests to test the "happy path" (elastic#79284 exists in order to expand to more tests for rule editing and creation.) * Wait for alert list API request to complete before clicking "Create rule" button when running the test to create a rule from the Stack Management UI. I ran the e2e tests 100 times locally with no failures so I'm confident the flakiness has been addressed. Fixes elastic#114419. Fixes elastic#109205.
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
* Re-enable previously disabled APM E2E tests. * Round to the nearest second in `getComparisonTypes` to avoid cases where a millisecond difference can change which results get shown. * Simplify error count alert tests to test the "happy path" (#79284 exists in order to expand to more tests for rule editing and creation.) * Wait for alert list API request to complete before clicking "Create rule" button when running the test to create a rule from the Stack Management UI. I ran the e2e tests 100 times locally with no failures so I'm confident the flakiness has been addressed. Fixes #114419. Fixes #109205. Co-authored-by: Nathan L Smith <[email protected]>
getComparisonTypes
to avoid cases where a millisecond difference can change which results get shown.I ran the e2e tests 100 times locally with no failures so I'm confident the flakiness has been addressed.
Fixes #114419.
Fixes #109205.