GitLab CI allows you to run tests much faster thanks to CI parallelisation feature. You can run parallel jobs across multiple GitLab Runners. In order to do it, you will learn how to split tests in a dynamic way across parallel tasks to ensure there is no bottleneck in GitLab Pipeline. Thanks to that CI build can be run as fast as possible so your Ruby & JS tests can be finely fast.
GitLab CI parallelisation
If you add more parallel GitLab Runners you also may notice that some runners can start work later or not all jobs can be started at the same time (for instance when you run GitLab Runners on your own infrastructure and other CI builds occupies some of the runners).
Dynamic test suite split to eliminate CI build bottlenecks
A solution to optimal tests distribution across parallel jobs (parallel CI nodes) is to distribute test files in smaller chunks across parallel GitLab runners. This ensures active runners can consume and execute your tests while too busy runners with slow tests would run fewer test cases. What is important is to ensure that all parallel runners will finish work at a similar time and thanks to that you won’t see stuck GitLab runner with too much work to process.
GitLab YAML config for parallel testing
Here you can find an example config
Please remember to set API token for Knapsack Pro as environment variable name
KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC in GitLab Settings -> CI/CD -> Variables (Expand) as a masked variable.
Note you can run dozens of parallel jobs by changing
parallel option and thanks to that run the very long test suite in a few minutes instead of waiting hour.
GitLab with its CI/CD tool allows to run fast CI builds thanks to parallelisation of your tests. By using Knapsack Pro Queue Mode you can ensure your tests are split across parallel jobs in an optimal way so your team gets test results as fast as possible.