How Parallel Github Actions Jobs Can Run Your RSpec Tests Faster in Ruby on Rails App

GitHub introduced their own CI server solution called  GitHub Actions. You will learn how to set up your Ruby on Rails application on GitHub Actions with YAML config file. To run your RSpec test suite faster you will configure parallel jobs with matrix strategy on GitHub Actions.

Automate your workflow on GitHub Actions

GitHub Actions makes it easy to automate all your software workflows with world-class CI/CD. Building, testing, and deploying your code right from GitHub became available with simple YAML configuration.

You can even create a few YAML config files to run a different set of rules on your CI like scheduling daily CI builds. But let’s focus strictly on how to get running tests for Rails app on  GitHub Actions.

Setup Ruby on Rails on GitHub Actions with YAML config

In your project repository, you need to create file

.github/workflows/main.yaml Thanks to it GitHub will run your CI build. You can find results of CI builds in Actions tab for your GitHub repository.

#github #ruby #ruby-on-rails #rspec #devops

What is GEEK

Buddha Community

Github Actions auto split of slow RSpec test file in parallel jobs for Ruby, Rails project

Splitting your CI build jobs between multiple machines running in parallel is a great way to make the process fast, which results in more time for building features. Github Actions allows running parallel jobs easily. In a previous article, we explained how you can use  Knapsack Pro to  split your RSpec test files efficiently between parallel jobs on GitHub Actions. Today we’d like to show how to address the problem of slow test files negatively impacting the whole build times.

Consider the split

Imagine you have a project with 30 RSpec spec files. Each file contains multiple test examples (RSpec “

its”). Most of the files are fairly robust, fast unit tests. Let’s say there are also some slower files, like feature specs. Perhaps one such feature spec file takes approximately 5 minutes to execute.

When we run different spec files on different parallel machines, we strive for similar execution time on all of them. In a described scenario, even if we run 30 parallel jobs (each one running just one test file), the 5 minute feature spec would be a bottleneck of the whole build. 29 machines may finish their work in a matter of seconds, but the whole build won’t be complete until the 1 remaining node finishes executing its file.

#github #github-actions #rspec #ruby #ruby-on-rails #test-automation #devops #good-company

How Parallel Github Actions Jobs Can Run Your RSpec Tests Faster in Ruby on Rails App

GitHub introduced their own CI server solution called  GitHub Actions. You will learn how to set up your Ruby on Rails application on GitHub Actions with YAML config file. To run your RSpec test suite faster you will configure parallel jobs with matrix strategy on GitHub Actions.

Automate your workflow on GitHub Actions

GitHub Actions makes it easy to automate all your software workflows with world-class CI/CD. Building, testing, and deploying your code right from GitHub became available with simple YAML configuration.

You can even create a few YAML config files to run a different set of rules on your CI like scheduling daily CI builds. But let’s focus strictly on how to get running tests for Rails app on  GitHub Actions.

Setup Ruby on Rails on GitHub Actions with YAML config

In your project repository, you need to create file

.github/workflows/main.yaml Thanks to it GitHub will run your CI build. You can find results of CI builds in Actions tab for your GitHub repository.

#github #ruby #ruby-on-rails #rspec #devops

Ruby on Rails Development Services | Ruby on Rails Development

Ruby on Rails is a development tool that offers Web & Mobile App Developers a structure for all the codes they write resulting in time-saving with all the common repetitive tasks during the development stage.

Want to build a Website or Mobile App with Ruby on Rails Framework

Connect with WebClues Infotech, the top Web & Mobile App development company that has served more than 600 clients worldwide. After serving them with our services WebClues Infotech is ready to serve you in fulfilling your Web & Mobile App Development Requirements.

Want to know more about development on the Ruby on Rails framework?

Visit: https://www.webcluesinfotech.com/ruby-on-rails-development/

Share your requirements https://www.webcluesinfotech.com/contact-us/

View Portfolio https://www.webcluesinfotech.com/portfolio/

#ruby on rails development services #ruby on rails development #ruby on rails web development company #ruby on rails development company #hire ruby on rails developer #hire ruby on rails developers

Run RSpec files on Github Actions with parallel jobs use auto split of the spec file

Splitting your CI build jobs between multiple machines running in parallel is a great way to make your CI testing fast, which results in more time for building features. Github Actions allows running parallel jobs easily. In a previous article, we explained how you can use Knapsack Pro to split your RSpec test files efficiently between parallel jobs on GitHub Actions. Today we’d like to show how to address the problem of slow test files negatively impacting the whole build times.

Consider the split

Imagine you have a project with 30 RSpec spec files. Each file contains multiple test examples (RSpec “ it s"). Most of the files are fairly robust, fast unit tests. Let’s say there are also some slower files, like feature specs. Perhaps one such feature spec file takes approximately 5 minutes to execute.

When we run different spec files on different parallel machines, we strive for similar execution time on all of them. In a described scenario, even if we run 30 parallel jobs (each one running just one test file), the 5 minute feature spec would be a bottleneck of the whole build. 29 machines may finish their work in a matter of seconds, but the whole build won’t be complete until the 1 remaining node finishes executing its file.

Divide and conquer

To solve the problem of a slow test file, we need to split what’s inside it. We could refactor it and ensure the test examples live in separate, smaller test files. There are two problems with that though:

First, it needs work. Although admittedly quite plausible in a described scenario, in real life it’s usually not just the one file that’s causing problems. Oftentimes there is a number of slow and convoluted test files, with their own complex setups, like nested before blocks, let s, etc. We’ve all seen them (and probably contributed to them ending-up this way), haven’t we? ;-) Refactoring files like that is no fun, and there seem to always be more higher prio work to be done, at least from our experience.

Second, we belive that the code organization should be based on other considerations. How you create your files and classes is most likely a result of following some approach agreed upon in your project. Dividing classes into smaller ones so that the CI build can run faster encroaches on your conventions. It might be more disturbing to some than the others, but we feel it’s fair to say it’d be best to avoid — if there was a better way to achieve the same…

Enter split by test examples

As you certainly know, RSpec allows us to run individual examples instead of whole files. We decided to take advantage of that, and solve the problem of bottleneck test files by gathering information about individual examples from such slower files. Such examples are then dynamically distributed between your parallel nodes and run individually, so no individual file can be a bottleneck for the whole build. What’s important, no additional work is needed — this is done automatically by the knapsack_pro gem. Each example is run in its correct context that’s set-up exactly the same as if you had run the whole file.

If you are already using Knapsack Pro in queue mode, you can enable this feature just by adding one ENV variable to your GitHub Actions workflow config: KNAPSACK_PRO_RSPEC_SPLIT_BY_TEST_EXAMPLES: true (please make sure you’re running the newest wersion of knapsack_pro gem). After a few runs, Knapsack Pro will start automatically splitting your slowest test files by individual examples.

#testing #rspec #rails #github #github-actions

Caching Ruby Gems on Github Actions Using ruby/setup-ruby or actions/cache

How do you cache Ruby gems on Github Actions CI? There are actually 2 ways of doing it with ruby/setup-ruby or actions/cache.

How to start CI build faster by loading Ruby gems from cache on Github Actions? You can start running your tests for a Ruby on Rails project quicker if you manage to set up all dependencies in a short amount of time. Caching can be helpful with that. Ruby gems needed for your project can be cached by Github Actions and thanks to that they can be loaded much faster when you run a new CI build.

You will learn how to configure Github Actions using:

• actions/cache — it’s a popular solution to cache Ruby gems.
• ruby/setup-ruby — it’s a solution to install a specific Ruby version and cache Ruby gems with bundler. Two features in one action.

Actions/cache — Just Cache Dependencies

Actions/cache is a popular solution that can be used to save data into the cache and restore it during the next CI build. It’s often used for Ruby on Rails projects that also use actions/setup-ruby for managing the Ruby version on Github Actions.

Let’s look at the Github Actions caching config example using actions/cache.

## .github/workflows/main.yml
name: Main
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - uses: actions/cache@v2
        with:
          path: vendor/bundle
          key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}
          restore-keys: |
            ${{ runner.os }}-gems-

      - name: Bundle install
        env:
          RAILS_ENV: test
        run: |
          bundle config path vendor/bundle
          bundle install --jobs 4 --retry 3

#ruby #testing #tech #github #ruby on rails #cache #tests