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 . GitLab CI Ruby & JS tests can be finely fast 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 can take quite a long time to execute. Cypress test runner as browser testing 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. It is important 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 . Below I will explain how Queue Mode works and what problems it solves. split tests in a dynamic way for Ruby & JavaScript tests you can use Queue Mode in Knapsack Pro GitLab YAML config for parallel testing Here you can find an example config for Ruby on Rails project that has RSpec tests executed across 2 parallel jobs using . The similar configuration would be for JavaScript projects with Jest or Cypress tests ( in Knapsack Pro can be found here). .gitlab-ci.yml Knapsack Pro Queue Mode full list of supported test runners Please remember to set API token for as environment variable name in GitLab Settings -> CI/CD -> Variables (Expand) as a masked variable. Knapsack Pro KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC # .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 jobs by changing parallel option and thanks to that run the very long test suite in a few minutes instead of waiting hour. parallel Summary with its CI/CD tool allows you to run fast CI builds thanks to parallelisation of your tests. By using you can ensure your tests are split across parallel jobs in an optimal way so your team gets test results as fast as possible. GitLab Knapsack Pro Queue Mode If you are looking for an optimal CI solution for your project, check out our comparisons: , , , or providers. GitLab CI vs Github Actions GitLab vs Circle CI Jenkins vs GitLab CI GitLab vs other CI Previously published at https://docs.knapsackpro.com/2019/how-to-run-parallel-jobs-for-rspec-tests-on-gitlab-ci-pipeline-and-speed-up-ruby-javascript-testing

Speed up your automated tests

Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

Use GitLab's CI/CD Tool to Run Parallel Tests

Too Long; Didn't Read

People Mentioned

@knapsackpro

RELATED STORIES