-
-
Notifications
You must be signed in to change notification settings - Fork 522
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
ci: run ci build related tests in parallel #1907
base: main
Are you sure you want to change the base?
Conversation
01f8ed3
to
550610d
Compare
|
||
- name: Node.js tests | ||
run: pnpm test:node | ||
|
||
test_browser: |
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's worth noting that ~85% of the test runtime is occupied by Playwright tests. We have around 200 tests there, and GitHub machines only has 2 cores, which means we are running all of them sequentially. This is the main bottleneck of CI performance for us right now.
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.
yep, totally.
In some cases though, being able to re-run the playwright tests a few times would be nice even if that was 7minutes each, without needing to rebuild, and run the other suites first. 3 minutes each x 5 runs is 15 minutes saved wall clock
Updates the
ci build
job to run each of the test suites in parallel instead of serialThis should save some wall clock time when running the tests in ci, since browser tests can start immediately after build instead of only after unit, node, and native tests complete
We'd likely want to extend the required jobs configuration once this lands to require each of the test jobs to pass
In main, the current
build
job is almost 10 minutes walltimein this branch it's closer to 7minutes, because each of the node/unit/native/browser suites run in parallel and avoid blocking eachother. the browser suite takes most of that wall-time still, but at least test suites won't block eachother
the big value, is that we can re-run one of these separate from the others