Split core's server-side integration tests into multiple suites

[pgayvallet]

Summary

Given we will have to move the integration tests to their own packages at some point anyway, this PR extract them from their current domain folder and move them to src/core/server/integration_tests/{domain}.

Each domain now has its dedicated integration test config (jest.integration.config.js), which will allow CI to run them independently, therefor increasing the overall CI IT run performances.

In addition, that allow to get rid of the domain folders that were still present in src/core/server just because there was a remaining integration_tests folder in it.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[TinaHeiligers]

Nice work!
I wish we could do something similar for the functional tests.

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 3898173
• Storybooks Preview

Metrics [docs]

✅ unchanged

History

• 💚 Build #58526 succeeded 86db252
• 💔 Build #58325 failed cf8d6dc
• 💔 Build #58277 failed a9ee639
• 💔 Build #58263 failed 68647f8

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

[gsoldevila]

Very interesting PR! 👏🏼

I’ve checked some CI builds before and after the PR and it seems that have some re-arrangement of the workload in the 2 CI jobs for integration tests:

Before

• Jest Integration #1: 25-28m
• Jest Integration #2: 45-48m

After

• Jest Integration #1: 35-37m
• Jest Integration #2: 35-37m

It seems that overall the 2 “nodes / jobs / runners / tasks” are more balanced, so if I understood correctly we reduced ~10 minutes from the overall time for Integration tests.

[pgayvallet]

It seems that overall the 2 “nodes / jobs / runners / tasks” are more balanced

Yea, that was precisely the intent, to allow CI to dispatch the IT suites properly, which was not possible previously because all our IT tests were included in the same single suite.