[INFRA] Parallelize the Buildkite test job on PR

[1Copenut]

Summary

This job will update our Buildkite test to parallelize linting, unit testing, and Cypress e2e testing against React [16, 17, 18].

QA

QA will be done manually by verifying the test runs on Buildkite UI.

• Linter ran successfully
• Jest unit tests ran
• Cypress ran on React 16
• Cypress ran on React 17
• Cypress ran on React 18

---

[1Copenut]

My only conceit on this PR is to make the Docker image smaller, because each command is run by a separate agent with no knowledge of other agents. I'm seeing several opportunities to reduce the size and speed up our Docker image caching. I'll roll that work into removing the Puppeteer step from Dockerfile later this week or next.

[1Copenut]

Originally I used if / elif / fi blocks but it was getting hard to read. This felt cleaner and more scalable.

[kibanamachine]

Preview staging links for this PR:

• Docs site: https://eui.elastic.co/pr_7197/
• Storybook: https://eui.elastic.co/pr_7197/storybook

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 09fe4e8

History

• 💚 Build #647 succeeded 779c584
• 💚 Build #645 succeeded 2818174
• 💚 Build #641 succeeded 4d04d63
• 💔 Build #640 failed 3c4493c
• 💔 Build #639 failed 7967c91
• 💚 Build #633 succeeded 0902f9a

cc @1Copenut

[breehall]

I'm no BuildKite expert, but this was very interesting to walk through! And to see all of these run in about 20 minutes is very cool! I'm not sure what it looked like with if/elif/fi, but the structure that you use in pipeline_test.sh feels very clean and easy to read.

[cee-chen]

1. Why assign a PR to Tomasz and not wait for his review on it?
2. Our Jest tests should be on multiple React versions as well, not just our Cypress tests. I believe we discussed this in our meeting yesterday - what happened with that?

[1Copenut]

Fair questions. I looked at Tomasz's schedule today and it looked like he was extremely busy, so I widened the PR. I've got bandwidth this week, so I'll work on testing Jest against multiple React versions also.

[cee-chen]

I recall requesting during yesterday's meeting that we update the issue to reflect that all tests, not just Cypress, should be run on different React versions. The issue should have been updated and this PR should not have been merged without fully completing the issue as specified (or if the PR was intended to only partially complete the task, that should have been made clear in the PR description and the issue should remain open).

[cee-chen]

and it looked like he was extremely busy, so I widened the PR

I get that this happens, but in the future I strongly suggest verbally documenting that thought process and pinging the reviewer in question to confirm that that's the case. Or if there's a pressing need to merge sooner rather than later (e.g. release schedules, ongoing merge conflicts, etc.) I would at least add a postscript saying "[person who hasn't had time to review], please feel free to review post-merge and I'll open up a follow-up PR with requested changes". A little extra communication can go a long way to making a PR not feel like it was rushed through before someone had a chance to take a look.