How to end fruitless dev discussions about your project’s code style?

Every developer has his little (weird) style variations. For instance, I do not add a space between an if and its parenthesis. As a dev team grows, these variations clutter the code base. And when you open a code request, the last thing you want to read is a comment on code style. You expect constructive comments on your code's architecture or the Single Responsability Principle not being respected. To totally cut on style related discussion, the tool you should use is a code linter.

We recently decided to migrate our projects from Gitlab to Github and used the opportunity to add one to our project. Rubocop was chosen for its completeness. The tricky part was to integrate its warnings into our pull requests on Github. The solution implies Jenkins CI, Pronto and Rubocop.

Pronto to the rescue

Rubocop cannot be plugged to a Github pull request out of the box. For that, you need Pronto which is a code analysis tool that can be used to post code style infringements as pull requests’ comments (Github and Gitlab). You can find different runners (brakeman, fasterer, jshint…) on Pronto’s Github. Currently, we only use pronto-rubocop. Note that the linter will only run on the pull request's modified code.
Add pronto and pronto-rubocop to your gemfile.

Jenkins and Github CI configuration​

We are now going to setup Github Pull Request Builder, a Jenkins plugin. First, install the plugin on your Jenkins. Next, go to “Manage Jenkins”, then “Configure System” and scroll to “Github pull requests builder” section.

You can test your configuration by posting a comment on a pull request from the plugin configuration page.​ Make sure you have an open pull request in your project beforehand then click on the “Comment to issue” button.

We are now going to setup our Jenkins to receive notifications when a new pull request is created on Github.

• Create a new Jenkins task, then elect “Github project” and add the url of your project like “https://github.com/my-organisation/my-project”
  Set the source code management to Git and set the repository URL.
• Enter the bot’s credentials.
• In Branches to build, set the specifier to “${sha1}”. Still in the source code management section, go to “Advanced” and set the name to “origin” and the Refspec to:

refs/pull/*:refs/remotes/origin/pr/*

• In the “Build Triggers” section, tick “GitHub Pull Request Builder”. This will open a new section where you have to tick “Use github hooks for build triggering”.
• Then click on “Advanced” and add your Github organisation at “List of organizations. Their members will be whitelisted”.
• You also need to add a step to the build, that is running Pronto on a Jenkins build triggered by a pull request.
• Choose “Execute a shell script”. Here’s the script:

#!/bin/bash
source “$HOME/.rvm/scripts/rvm”
bundle install — without=production console
GITHUB_ACCESS_TOKEN=YOUR_TOKEN PULL_REQUEST_ID=$ghprbPullId bundle exec pronto run -f github_pr -c origin/$ghprbTargetBranch

You can set the GITHUB_ACCESS_TOKEN environment variable pronto.yml.

• To get your OAuth token go to : https://help.github.com/articles/creating-an-access-token-for-command-line-use/.

You might have to change the source instruction according to your Jenkins setup, or remove it altogether.

Conclusion

We now enjoy Rubocop's comment directly in our pull requests!

Having this bot commenting on our pull requests is really an incentive to keep our code clean and maintainable. We also learn new rules on the way.
The next step would be to add a pre-commit hook that prevents us from committing if there are any code style rule violations in an edited file.

This article was written by Appaloosa's dev team:
Benoît Tigeot, Robin Sfez, Alexandre Ignjatovic, Christophe Valentin

Want to be part of Appaloosa? Head to Welcome to the jungle.