How to Run GitLab CI Pipeline With Parallel RSpec Tests in Ruby
Join the DZone community and get the full member experience.Join For Free
GitLab CI allows you to run tests much faster thanks to its CI parallelization 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 and JS tests can be finely fast.
GitLab CI Parallelization
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 occupy 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 the
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 you to run fast CI builds thanks to parallelization 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.
Published at DZone with permission of Artur Trzop. See the original article here.
Opinions expressed by DZone contributors are their own.