How to Run GitLab CI Pipeline With Parallel RSpec Tests in Ruby

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

The common problem when you want to run tests in parallel to complete your one-hour test suite in a few minutes instead of waiting hours is to find a way to split tests on parallel jobs. Some of your Ruby or JavaScript tests can take milliseconds and some even a few minutes per test file (for instance, when using Capybara in RSpec features testing). The problem with slow tests also occurs in E2E (end to end testing) when using Cypress test runner as browser testing can take quite a long time to execute.

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.

To split tests in a dynamic way for Ruby & JavaScript tests you can use Queue Mode in Knapsack Pro. Below, I will explain how Queue Mode works and what problems it solves.

GitLab YAML Config for Parallel Testing

Here, you can find an example config .gitlab-ci.yml for Ruby on Rails project that has RSpec tests executed across two parallel jobs using Knapsack Pro Queue Mode. A similar configuration would be for JavaScript projects with Jest or Cypress tests (here is a full list of supported test runners in Knapsack Pro).

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.

# .gitlab-ci.yml

image: "ruby:2.6"

services:

  - postgres

variables:

  RAILS_ENV: test

  POSTGRES_DB: database_name

  POSTGRES_USER: postgres

  POSTGRES_PASSWORD: ""

  DATABASE_URL: "postgresql://postgres:postgres@postgres:5432/database_name"

  # KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC: it is set in Settings -> CI/CD -> Variables (Expand) as masked variable

before_script:

  - apt-get update -qq && apt-get install -y -qq nodejs

  - ruby -v

  - which ruby

  - gem install bundler --no-document

  - bundle install --jobs $(nproc)  "${FLAGS[@]}"

  # Database setup

  - bin/rails db:setup

rspec:

  parallel: 2

  script:

    - bundle exec rake knapsack_pro:queue:rspec

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.

Summary

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.

If you are looking for an optimal CI solution for your project, check out our comparisons: GitLab CI vs. GitHub Actions, GitLab vs Circle CI, Jenkins vs. GitLab CI, or GitLab vs. other CI providers.