-
Notifications
You must be signed in to change notification settings - Fork 5
Description
Details from https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/184#note_668294739
Using an ever longer delay is not a good way of doing these tests, they don't scale. Ideally we fix this up before going into prod.
I also noticed our tests taking longer now. Up to 30 minutes.
To speed up our testing, we can parallelise our testing. Now our jest tests are naturally parallelised by checking the number of cores the host environment has. But the CI/CD runners all have 1 CPU core:
If you’re using the GitLab.com 32 autoscaling shared runners, I believe the runners have 1CPU, 4GB RAM, and 22Gb of storage (16Gb available).
There should be a way for us to configure with more cores or other wise increase the number of parallel jobs by splitting the test job, which would end up using multiple runners (somewhat inefficient) due to duplication of resources, and then adding our own custom runner with more cores.
- https://docs.gitlab.com/runner/configuration/autoscale.html
- https://about.gitlab.com/blog/2021/01/20/using-run-parallel-jobs/
- https://docs.gitlab.com/ee/ci/yaml/#parallel
- https://docs.gitlab.com/ee/user/gitlab_com/#gitlab-cicd
A quick way to do this would to be create separate CI/CD jobs for each domain run. So npm test tests/X and npm test tests/Y might allow us to take advantage of gitlab CI/CD's splitting of each job in parallel. Only issue is the sharing of the Nix environment.
Tasks
- - Investigate dynamic parent child pipelines
- - Test splitting can be automatic by splitting a pipeline for each subdirectory under
tests/* - - For all the immediate files in
tests/*they can run under a single test pipeline