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 logo

GitLab CI parallelisation

The common problem, when you want to run tests in parallel to complete your 1-hour test suite in a few minutes instead of waiting hours, is to find a way how 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). 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 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.

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 2 parallel jobs using Knapsack Pro Queue Mode. The similar configuration would be for JavaScript projects with Jest or Cypress tests (full list of supported test runners in Knapsack Pro can be found here).

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 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 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.

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.