[Security Solution] Removing cleanKibana method from Cypress

[MadameSheema]

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.

As part of this effort, we are trying to make our Cypress tests more robust and reliable.

While testing the pipeline, we have seen that cleanKibana() method is a bit flaky on MKI. That might be because we are deleting too many things when it is not actually necessary.

Most of the tests use it on the before hook. This is not needed anymore since each spec file is executed in its own newly created project.

In this PR

In this PR we are removing cleanKibana from our Cypress tests in favor of cleaning just what we need instead of everything.

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[janmonschke]

Now this one is interesting. Can you elaborate why we need to login now and before we didn't need to?

[MadameSheema]

I might messed up when solving conflicts :D

I'll revisit, thanks ❤️

[MadameSheema]

For what I see we were doing a login on beforeEach, but just with the before hook is enough, we don't need to login twice :)

[janmonschke]

THI changes look good to me

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: b14b80a

Metrics [docs]

✅ unchanged

History

• 💚 Build #173481 succeeded e6f5c2d

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

cc @MadameSheema

[PhilippeOberti]

except for Jan's comment, everything else LGTM for the Threat Hunting Investigations team.
Awesome cleanup thank you! :)

[vitaliidm]

detection engine area LGTM

[jpdjere]

Rule Management LGTM 👍

@MadameSheema To fully understand these ongoing changes: the running of each spec in its own separate project happens in CI for PRs as well, or only for QA/MKI quality gates?

Just making sure to prevent that we re-introduce flake for PR pipelines by removing all these cleanKibana() calls.

[MadameSheema]

Rule Management LGTM 👍

@MadameSheema To fully understand these ongoing changes: the running of each spec in its own separate project happens in CI for PRs as well, or only for QA/MKI quality gates?

Just making sure to prevent that we re-introduce flake for PR pipelines by removing all these cleanKibana() calls.

Happens in CI for PRs and MKI quality gates. On CI with the FTR serverless and ESS environments we didn't find flakiness, we started to see it on real serverless projects. That might be also related because real serverless projects are slower than the environments we use to execute tests on PRs.