Inkycop - Standardizing team configuration for RuboCop

How Custom Ink unifies its code base across projects.

Ruby Coding Guide

I'm sure that every developer is familiar with the concept of a coding guide to ensure that everyone working on a project is writing the same code. This ensures that the code style remains consistent, and the overall quality of the code is guaranteed. Of course this doesn't come without its share of problems and difficulties.

As it stands right now, Custom Ink has just over 800 different repositories on GitHub, the majority of them being Ruby projects. As we have multiple teams working across these projects, we need to come up with some way to keep a uniform code style.

RuboCop

Almost all of our Ruby projects use RuboCop through CodeClimate. While this is a good step in the right direction, it does not guarantee that all projects also adhere to the same style guidelines. After all, nothing prevents an engineer from disabling a rule, changing its configuration or outright ignoring the messages from CodeClimate.

CodeClimate

As mentioned above, we use CodeClimate. We, however, do not always see eye-to-eye with the warnings and issues raised by CodeClimate. Mainly because a team might have a different view on things, there's a reason why we want to deviate or something is technically not possible. There are also technical limitations imposed by CodeClimate that make it hard to do certain technical solutions.

Meet InkyCop!

Inky is the mascot of Custom Ink. Our lovely octopus is a part of the company, and seeing we actually depend on RuboCop, I came up with the name InkyCop. So what is InkyCop exactly?

InkyCop is a gem developed for internal usage at the moment, where we have created several configuration files:

• a special customink.yml file that contains the general configuration for all RuboCop cops, regardless of Ruby version
• a special folder structure to support ruby-specific rubocop.yml versions for that Ruby version
• a special folder structure to support RuboCop-plugins such as rubocop-rails and rubocop-rspec

This allows us to create a matrix of configurations that we can tweak to support all Ruby versions that are supported by RuboCop, and used inside the company. Of course, we need to work on getting everything up to date, but this is a tremendous amount of work that will take time, and it's easier to support the version through RuboCop.

Our merchandising system is actually the first system to rely on InkyCop! Its configuration file looks as follows:

# The load order is first those defined by inkycop, then everything in the todo file,
# finally whatever is appended later in this file.
inherit_from: .rubocop_todo.yml

inherit_gem:
  inkycop:
    - config/rspec/2.3/rubocop.yml
    - config/customink.yml

That's it! nothing more needs to be added or configured to use all of RuboCop features, and rely on the shared configuration that's defined in our Gem.

Issues we ran into

Getting InkyCop successfully integrated was no easy-feat. There's actually quite a few technical details that need to be kept in mind when creating this gem. Even though the gem in itself is nothing more than a simple wrapper around RuboCop with custom configuration files:

• CodeClimate does not work for InkyCop. CodeClimate does not allow the usage of external gems during their RuboCop engine. This results in their engine crashing because the inkycop gem is not checked out.
• To work around this problem, we actually switched to CircleCI (for other reasons) and made the RuboCop check a part of the CI.
• A build is now considered a failure if the RuboCop check does not pass.
• RuboCop must be executed using bundle exec or with a binstub.
• The naming of the configuration files was important! Note that we called our files rubocop.yml and not .rubocop.yml inside the gem.

RuboCop file names

There is a subtle difference on how RuboCop interprets paths, depending on how your configuration files are named. This took some debugging as well as diving deep into the documentation of RuboCop to understand and figure out.

• .rubocop.yml : All paths are treated as relative of the file's location
• rubocop.yml : All paths are treated as relative of the location RuboCop is running from

While this seemed to work properly at first, it becomes more tricky when files start inheriting from one another and/or files are combined as we do. That's why we made this an integral part of our documentation to make sure this information is well known.

Upcoming challenges

The next step is get all projects to migrate slowly to using InkyCop, so we can start tweaking our configuration. There's going to be a lot of discussion on whether we will follow the standard set by RuboCop, or tweak a Cop to our liking. In the end, all teams will have to agree to it, and roll out with InkyCop to unify the coding guidelines across the entire code-base.