Set Up GitLab CI for Rails Applications

It is hard to go back, once you integrate CI/CD flow into your workflow. Luckily, tools like GitLab are great, as they provide not only a nice GIT hosting platform, but a robust continues integration and delivery platform.

Let’s set up our .gitlab-ci.yml file, so it meets our needs.

First Steps

We will use the official Ruby docker image as a start and add PostgreSQL service. It is a good idea to cache our dependencies as this will remove the need to download them if there are no changes.

Before Script

The before_script is the place, where you can put your setup steps that will run before every stage. Here we will put the installation of additional software that we need and the initial setup of the project, like running migration, compiling assets, etc.

Take a note that we copy our CI specific database configuration file, which contains the correct values for the runner. It should have the following content:

Defining the Stages

The stages block of the config file defines all the stages of the build process of the app. We, at Evermore, usually go with three: test, lint and deploy.

Test Stage

GitLab allows having as many tasks per stage as you like, which makes perfect sense for our unit and system tests. But to be able to run tests using headless Chrome, we need to install it and install chromedriver as well. As this is kind of expensive task, we only do it when we actually need it.

Here is the ./bin/setup_chrome file

Lint Stage

At Evermore we have a coding style guide and one thing that we like to do is to automate the review process of lint violations. It is always a better idea if they come from a machine than a person. To do this we use this awesome gem called pronto. It has various runners and rubocop is one of them.

As this is not the curtailed part of our build, we allow failures for this task. And, of course, there is no need to run this task on the master branch, because we want to lint only the change in a pull (merge) request.

Deploy Stage

Deploy stage can be different depending on the needs. We usually use Heroku and have two environments — staging and production. We deploy to staging on successful build on branches (pull requests), so it is easy to review and deploy the master branch to production.

The easiest way to deploy your app to Heroku, is using the dpl package. You just need to install it and setup an API key.

Do not forget to add `$HEROKU_API_KEY` to your secret variables in GitLab.

Here is the ./bin/setup_heroku file

We install Heroku’s CLI tool, so we can run tasks like migrations, seeding the database and so on.

And We Are Done

Of course, we can go a step further and create a custom docker image. This way we will cache some of the setup steps and speed up the builds. Strangely enough, I was not able to find an image that fits my needs for this specific project, so I created one — https://hub.docker.com/r/mupkoo/rails-ci/.

Here is the full script. Tweak it and make it yours. Good luck!