(Semi)Automated code review
Automation of a Github code review process with Pronto and Circle CI
As your team grows you start noticing subtle differences with the way your team members write and format code. For smaller teams it’s not a big issue but imagine team with dozens of developers, each one of them organizes and formats code differently. After a while app is a mess. Sounds disturbing? I should have mentioned every one of them has different experience and standards for what’s “good enough”.
You may find yourself very often writing the same Pull Request comments just to keep codebase consistent and up to date with chosen style guide. How many of “use guard clause” or “this line seems to be too long” or “this variable is never being used” have you written so far? Well for me it was definitely too often and I decided to look for available solutions. After a moment or two I’ve came across Pronto gem.
They way out — Pronto
Pronto (https://github.com/mmozuras/pronto) is gem for code static analysis automation. Its biggest advantage is ability to analyze only most recent changes (so it can be used for existing projects without adding too much noise) and post violations as comments directly to Github, Gitlab or Bitbucket.
First thing you have to do is to add gem, its runners and dependencies to Gemfile and run bundle install
This will make pronto command available within our test environment. In next step we’ll make sure automatic code review is being made on pull request creation. For this purpose we will use Continuous Integration service CircleCI.
Setting up Circle CI
I’m going to use Circle CI as a trigger for our code review. If you don’t have it setup yet please go to https://circleci.com/docs/1.0/language-ruby-on-rails/ for further instructions. You can use different tool (such as Jenkins) but please keep in mind it may require some changes in script from the next step.
Assuming you have Circle CI in place go to your project settings and make sure you have “Only build pull requests” turned on. This way we will make sure code review is being performed only after Pull Request is created (we will need Pull Request ID to submit comments)
Next thing you have to do is to setup circle.yml configuration file. We need to add two things:
- modification of the way CircleCI performs fetch — by default it downloads only small part of git history making diff comparison impossible
- running script file bin/automated_code_review that we’re going to create in the next step
This can be done with following lines:
At the end you have to setup PRONTO_GITHUB_ACCESS_TOKEN environment variable. You will get access token from your Github account in “Personal access tokens” tab. All you have to do is to place it inside your build settings under “Environmental variables”
Having all those things set up we can move to last step which is creating code review script
Creating code review script
By default Pronto compares changes agains master branch. In my case it was not always desired state because sometimes Pull Requests were branched off from branches different than master. For such a situation I’ve prepared short script that asks Github API for Pull Request base branch, and uses it as base for Pronto diff calculations.
Don’t forget to change rights of the file with chmod 755 bin/automated_code_review, only this way Circle CI will be able to execute file.
How it looks?
If everything works correctly once you try to submit all those changes and you will create a Pull Request you should see new Github statuses and maybe even some comments:
From this point you can start customizing all linters with files like .rubocop.yml added to your repository or maybe even add your own runners. It is also possible to plug in pronto on your before_commit hook but I’ll let you assess whether it’s good approach or not.
Thanks for reading. If you liked this article you may be also interested in our best practices on keeping code clean: http://exlabs.co.uk/best-practices-on-keeping-your-codebase-clean/. Please clap your hands it if you like it :)
