How to automatically review your PRs for style violations with Pronto and RuboCop
Is sloppy written code slowly creeping into your codebase? Finding tabs in your source files, but the team is using spaces? You research on a freshly merged PR, but the code has zero comments on classes or modules?
I’m guilty of all the points raised above. I’ve previously written about how you can use Pronto to check for style violations when committing your code.
Truth be told, the solution detailed in that blog post isn’t for everybody, and doesn’t work in all situations. You might be in a hurry, cause you need to pick up your kids from school, and you just wanna commit that code and push it. You ignore the warnings raised by RuboCop, and send it off for your team to review.
What if there would be somebody reviewing your PRs, leaving you actionable comments on violations, and even giving you and your team the chance to discuss the bad spot in your code, even ticking it off as “good enough for now”?
Luckily, Pronto can do it all. In this blog post I’ll walk you through the steps to integrate Pronto with Codeship and GitHub. I’m assuming you already have your tests running on Codeship’s platform.
Pronto - the swiss army knife for code reviews
The command we wanna run is documented in the Pronto README on GitHub:
PRONTO_GITHUB_ACCESS_TOKEN=token PULL_REQUEST_ID=id pronto run -f github_status github_pr -c origin/master
This will both set the GitHub status of the PR specified in the
PULL_REQUEST_ID environment variable, and create comments on the PR. Note that this will only diff the changes in the PR with the branch you’ve specified in the
-c flag (so
origin/master here), so you don’t need to worry about a ton of reported violations, as it often happens with a legacy codebase.
Getting the GitHub API Token
To set the commit status and to post comments on the PR on GitHub, we gonna need to supply an API token to Pronto. For the sake of simplicity, I’ll use my personal access token. In real life you probably want to generate a new GitHub account (something named like review-bot) and use that instead of your personal account.
You’ll find the API token under Settings > Developer settings > Personal access tokens. We’ll also need to select the following scopes:
repo:status. Note that GitHub will automatically select a broader scope as you can see in the following screenshot:
Once we have the token, we can add an environment variable to our Codeship project, named
PRONTO_GITHUB_ACCESS_TOKEN, and paste the API token.
Finding the GitHub Pull Request ID
The next thing we need is the Pull Request ID. That’s the number you see in the permalink of a PR.
Unfortunately, Codeship doesn’t expose that ID in an environment variable. That’s not a big issue though, as we can easily get it ourselves.
We gonna need the commit hash for this, which is stored in
CI_COMMIT_ID. Next, we query the PR branches on GitHub for that commit, extract the ID and put it into an environment variable:
export PULL_REQUEST_ID="$(git ls-remote -q origin pull\*\head | grep $CI_COMMIT_ID | sed 's/.*refs\/pull\/\([0-9]*\)\/head/\1/g')"
Putting it all together
Now we can open our project settings, and edit the existing test command for our pipeline:
1 2 3 4 5 6
export PULL_REQUEST_ID="$(git ls-remote -q origin pull\*\head | grep $CI_COMMIT_ID | sed 's/.*refs\/pull\/\([0-9]*\)\/head/\1/g')" <your existing test commands, e.g. bundle exec rake> git fetch origin master:refs/remotes/origin/master pronto run -f github_status github_pr -c origin/master
You’ve probably noticed that I’ve put an additional line in here, right before we’re invoking
pronto. That is because Codeship doesn’t fetch the
origin/master branch by default, so we have to do that manually.
If we now when we open up a new PR on GitHub, we’ll see a similar status like this one here in our PR after a few minutes: