DEV Community: Andy Waite

A GitHub Actions Rails CI Workflow in 5 lines

Andy Waite — Fri, 15 Apr 2022 00:00:00 +0000

A few years ago, Matt Swanson wrote a great post on setting up Rails CI on GitHub Actions. It quickly became my go-to reference for setting up CI for new apps.

Over time, I made few updates and adjustments to it, so whenever I started a new project I would copy the config from one of my older projects. But this meant each project gradually became inconsistent, and some got updated more than others.

I wanted to have one single base workflow for all my apps, so that if I made a change, all the apps could easily benefit from it.

Reusable Workflows

In November 2021, GitHub announced that Reusable Workflows was generally available.

Although GitHub Actions has supported composite actions for a long time, Reusable Workflows allows for a much more concise configuration, and the ability to reference a whole workflow from another repository, rather than having to build up each step individually.

Introducing setup-rails

I’ve published setup-rails as a reusable workflow for quickly and easily enabling CI for Rails apps.

By creating a single file in your repo, e.g. .github/workflows/verify.yml, with the contents below, you should a have working CI workflow which configures the database and runs your app’s tests:

name: Verify
on: [push]

jobs:
  verify:
    uses: andyw8/setup-rails/.github/workflows/verify.yml@v1

You can take a look at this example app to see it in action.

The first time you run the workflow may be slow, but subsequent runs should be much faster once the dependencies are cached.

I’ve also shared a Railsbyte so that you can set this up with one command:

rails app:template LOCATION="https://railsbytes.com/script/VMys8A"

Principles and Configuration

I designed setup-rails so it should work at a basic level with no configuration needed for most apps.

There are a few options you can enable depending on your app, such as RuboCop, Bundler Audit and RSpec - see the README for details.

Currently only Postgres is supported but I’d like to expand to cover at least MySQL.

Enhancements

Building upon Matt’s great starting point, I made a few updates:

Uses the latest versions of setup-node and setup-ruby
Adds support for rails test (e.g. Minitest) as well as RSpec
Enabled Dependabot for updates of the actions that setup-rails depends on
Uses setup-node’s JavaScript caching rather than a custom approach
Skips development gems when running Bundler to avoid unnecessary work.

Get Involved

I’m already using this on most of my apps, but I’d love to get wider feedback.

Please try setup-rails on your app and let me know how it works for you. Issues and pull requests are welcome!

Avoiding common cron pitfalls when scaling Rails

Andy Waite — Sun, 15 Mar 2020 00:00:00 +0000

A common theme in business applications is the need for some kind of periodic task to run at a fixed interval, such as daily or weekly. This is often used for activities such as billing, pushing data to other systems, or integrating with a third-party API.

The de facto tool to use for this is cron. It's somewhat archaic, but provides a reliable mechanism to declaratively define job schedules. The popular whenever gem provides an DSL to make this easy to use with Ruby.

Simple tasks such as clearing a cache are a great match for cron.
They run quickly and don't require significant system resources.

The difficulty comes when cron is used to execute tasks which rely on the Rails application. It's easy to make use of cron for this, because we call the rails runner command to invoke a method on a class.

On a small app, this approach may be fine, but when scaling up there are some serious drawbacks.

Whenever we use rails runner, we're launching a completely separate instance of the application. Let's say your Rails app typically uses around 200MB of memory. To allow for some growth, we provision a server with 512MB of memory. If you schedule a cron job, the server's memory usage will temporarily spike to to 400MB.

This might not even be noticed at first. Even if the machine runs short on memory, it can temporarily make use of swap space on disk.
This might happen in the middle of night, when traffic is already low.

But consider what happens once you have more scheduled jobs:

CalculateUsage runs daily at 2am
GenerateReports runs weekly at 2am (every Monday)
CreateInvoices runs monthly at 2am (first Monday of each month)

This means that once a month, all three jobs will be triggered at the same time. Your system needs to have enough capacity to run three instances, in addition to the main app.

This could mean you need to over-provision your servers by 4x. That extra capacity will be idle most of the time. On a large site, you could be spending thousands of extra dollars per month. Or if you don't sufficiently provision, then you risk crashing your site.

This risk is often exacerbated by the nature of schedule jobs.
A web request typically lasts only for a few seconds at most.
But a job may run for a much longer period, causing a large spike in memory use.

A First Approach

Let's take a step back, and consider how we schedule jobs. Is it critical that each jobs runs at 2am? Probably not. The key thing probably that the job is complete by the beginning of the business day.

A common first reaction to this problem is to try 'pad out' the jobs to prevent them overlapping. For example, instead of running each job at 2am, you run the first at 2.00am, the next at 2.05am, and the next at 2.10am.

While this may provide a short term fix, it's not a sustainable solution. As your data grows, the time it takes to run each job will creep up, and will start to overlap again. You'll end up playing Whac-A-Mole shifting jobs around.

A Better Approach

As with many scaling problems, we can handle growth better if we can scale horizontally and add additional machines.

We can achieve this with a distributed queue. In Rails, we typically use tools such as Sidekiq, Resque or Delayed Job.

We could even configure this to auto-scale to handle varying workloads.

Instead of using cron to execute the jobs, we'll use it to only enqueue them, e.g.:

job = MonthlyReport.new(Date.today)
Delayed::Job.enqueue(job, queue: 'cron')

This still involves booting up a separate Rails instance, but it's a fast operation. Spacing jobs one minute apart should be sufficient.

You may later run into another problem of timeouts from jobs being too large. That can often be handled with a map-reduce approach, but that's beyond the scope of this post.

Further Improvement

Instead of having to boot up an instance of the app just to enqueue a job, there's another approach we can take.

We can add an internal API endpoint, such as /api/internal/jobs. We can make an HTTP post, specifying the job to be enqueued. That means cron only needs to execute a call to something like curl, which uses vastly less resources. Obviously you should add some kind of authentication or restriction on the endpoint to avoid any possibility of a DOS attack.

Speed up your TDD by refactoring rails_helper.rb

Andy Waite — Sat, 14 Mar 2020 00:00:00 +0000

Having a fast feedback cycle is critical element of successful test-driven development. You should be able to run a single test within one second.

If you use rspec-rails, and your app has been around for more than a few years, the chances are that your rails_helper.rb has accumulated a lot of cruft. This increases the time it takes to run a single test, probably to several seconds at least. As this usually happens gradually, it often goes unnoticed by those who work in a codebase every day.Developers may become accustomed to waiting ten seconds or more to run a single test.

The default rails_helper.rb generated by the rspec-rails installer is minimal and fast. There are a variety of things which tend to be added which slow it down:

Seeds tasks (such as from seed_fu).
Requiring of all files within spec/support (older versions of rspec-rails defaulted to this but this approach is now discouraged by the RSpec team).
Global RSpec hooks such as Before and After
Libraries to manage database state, such as DatabaseCleaner
Setup for browser testing tools, such as Capybara
Miscellaneous other testing support libraries.

Some of these will have a much bigger impact than others. You can use profiling tools to better understand the contribution of each.

Overview

The key to speeding up the TDD cycle is to only load what’s needed for a specific test.This strays from Rails’ convention of having everything auto-loaded, but I would argue it’s a worthwhile trade-off.

(Note that this will probably not have any impact on your overall test suite time. The focus here is on the time for running an individual test or test file).

Refactoring your whole test suite at once could take some time, perhaps several days for a large app.We want to do it gradually, in small steps, so that test suite stays green. Here’s how:

Implementation

First, we rename the existing rails_helper.rb to something like legacy_rails_helper.rb.

We then update the existing references to that file with the new filename, which should be a simple global search and replace in your editor.

Run your tests suite to ensure everything is still passing.

Next, we create a ‘clean slate’ rails_helper. An easy to do this is by re-running the rspec-rails generator, i.e. rails generate rspec:install.

Now, find a relatively basic test in your test suite. It’s usually easier to start with focused unit tests rather than integration tests, since they typically have more dependencies.

Change the test to run with the new rails_helper.rb. If it passes, then great, we’re done.

Note that it’s important to verify that the tests passes individually. If you run the whole suite, a previously run test may have already loaded a necessary dependency. Since RSpec runs the tests in a random order, this may result in a false positive.

But what if the test fails? Hopefully the test output will indicate that the failure is due to a missing dependency.

There are a few courses of action you can take to resolve this.

You can determine what lines in legacy_rails_helper.rb are needed, and copy to your rails_helper.rb.
You can use custom hooks so that particular lines are only executed for tests that are tagged with that hook name.
You can copy only what’s required for that specific test.

Let’s talk about the pros and cons of each.

If we always copy the code back into rails_helper.rb then we’ll end up close back where we started. So I try to reserve that for dependencies which are used in a large number of tests, e.g. something like FactoryBot.

What about hooks? RSpec lets us run specific code for tests with a particular tag:

RSpec.configure do |config|
  config.before(:db) do
    require "some-library"
  end
end

This can be useful, but the downside is that we’re adding a layer of indirection. A developer reading this would need to know what a particular tag represents.

The last approach is to be explicit about of each test’s dependencies, for example:

require "rails_helper"
require "some-library"

Communicating the Change

If you’re working on a team, you’ll want to ensure that while the changeover is in progress, new tests are written using the new rails_helper.rb. This is something you could also add to your project’s README or developer documentation so that others joining the team are also aware.You could also use a custom RuboCop check.

Final Steps

Eventually, you’ll have moved every test over to the new rails_helper. You can now delete legacy_helper.rb. You may also discover there gems in your Gemfile which are no longer needed, and can be dropped. You may also be able to remove unused files from spec/support if they are no longer referenced.

Migrating from Mocha to rspec-mocks

Andy Waite — Sun, 15 Sep 2019 00:00:00 +0000

At Financeit, our main app uses RSpec for the test suite, but until recently it made use of Mocha (not to be confused with the JavaScript library of the same name) for stubbing and mocking.

We recently decided to switch to use rspec-mocks. Some reasons for this were:

We were already using rspec-mocks in other projects.
There are more reference and training materials for rspec-mocks (books, screencasts, blog posts, etc).
New developers joining the team were typically already familiar with rspec-mocks.

We didn’t have any problem with Mocha itself – it’s well-designed, has good documentation, and a responsive maintainer. The main reason was to have a simple and consistent stack.

Approach

As our test suite is large, we knew that an incremental approach would be preferable.

We made use of the rspec-multi-mock gem to allow Mocha and rspec-mocks to both be used at the same time.

We then introduced a policy that new specs should be written using rspec-mocks rather than Mocha. Our code review process helped to remind developers of this.

Next, we began the process of converting the test suite. Most Mocha has a direct mapping to rspec-mocks. I created this ‘cheatsheet’ for easy reference:

Mocha	rspec-mocks
`stub(a: 1)`	`double(a: 1)`
`mock(a: 1)`	`double(a: 1)`
`foo.stubs(:a).returns(1)`	`allow(foo).to receive(:a).and_return(1)`
`foo.expects(:a).returns(1)`	`expect(foo).to receive(:a).and_return(1)`
`Foo.any_instance.stubs(:a).returns(1)`	`allow_any_instance_of(Foo).to receive(:a).and_return(1)`

The most obvious way to make these conversions would be using regular expressions. And although this handles around 80% of conversions, the remainder would need to manually reviewed and edited, or would need very complex regular expressions.

As a general rule when changing code with automatic tools, it’s better to modify the AST (Abstract Syntax Tree) than to manipulate strings.

Ruby already has a powerful tools for this: RuboCop, which makes use of theparser gem, has an auto-correct feature to change code to follow a preferred style.

RuboCop Custom Cops

At Financeit, we have a concept of ‘spike weeks’ where developers get to work on something they have a personal interest in. This gave me an opportunity to explore this area.

RuboCop can be extended with custom cops – the documentation is somewhat limited, so it took some time to get the hang of, but after that I found it to be a very effective approach.

I worked through the app in stages, beginning with spec/controllers, thenspec/models, spec/services, etc.

The test suite itself helped to verify that the conversions were correct, since bad conversions should typically result in a syntax error, or a failing test.

I ran into a few situations where the conversion didn’t work because of some strange approaches in the test, so took the opportunity to re-write the test.

We’ve now converted around 95% of the test suite. We hope to soon reach 100%, when we can then remove the rspec-multi-mock and Mocha gems.

I’ve published the RuboCop custom cops as the mocha_to_rspec gem.