Get static analysis of your Pull Requests with Pronto
Tags: rubocop, pronto, ruby, rails
Published: 2017-08-14 17:47:18

---
title: Get static analysis of your Pull Requests with Pronto
published: true
description: Take advantage of your continuous integration build to analyze your code
cover_image: https://cdn-images-1.medium.com/max/1600/1*xxzCZ_x7oeKlq_NRTw6GeA.jpeg
tags: rubocop, pronto, ruby, rails
---

Almost in every programming language there are static analysis tools which evaluates code quality and check if it follows a series of basics rules of styling.

This is very important because in a project where many developers work, it will be easier to read, understand and collaborate with if everyone generates their code following a set of common rules.

In Ruby, for example, we have [Rubocop](https://github.com/bbatsov/rubocop) as reference to styling (and more) rules. These rules have been created and maintained by the ruby community.

Rubocop can be installed in our development environment and used in our day to day basis to check if the code we generate follows the Rubocop's style guide, however this procedure is not as effective as it should, because it depends on the developer to check and fix its code.

To improve this procedure we could use any of the multiple SAAS that already exists to do checks on our project's Pull Requests, like [HoundCI](https://houndci.com/), but if we already have a continuous integration system configured we won't need to delegate these checks to any new SAAS.

We can reuse our [CircleCI](https://circleci.com/) or [TravisCI](https://travis-ci.org/) (or the CI system of your choice) to launch our custom command of static analysis.

## Pronto

[Pronto](https://github.com/prontolabs/pronto) is a tool created specifically to check the changes made in a Pull Request, whether it is in Github, Gitlab or Bitbucket. It has many plugins which you can add depending of which aspects of your codebase you want `pronto` to check.

We are going to use a Rails application as test subject, in this case we will check style of our code with Rubocop.

## Configuration of the Rails application

First we have to install the required dependencies, because we are going to check only styling we need to install `pronto` and `pronto-rubocop` in `development` and `test` environments.

```ruby
group :development, :test do
  gem 'pronto',          require: false
  gem 'pronto-rubocop',  require: false
end
```

From now on we can use pronto cli tool to launch the style check. For example if we add the following Article class to our project and run pronto:

```ruby
class Article < ApplicationRecord
    def is_available?
      Time.now >= publish_on
    end
end
```

![example](https://cdn-images-1.medium.com/max/1600/1*uRB1KAhaJS904fxdjFtYWw.gif)


This way we can check the code that we just wrote before committing it, but we want this to be executed automatically, right?

## Analysis in our Pull Requests

The next step is to configure our test build to execute pronto when the build is successful, we can use the hooks that our CI provider gives us.

In this example we are using TravisCI so we'll modify its configuration file, `.travis.yml`, with the following configuration:

```ruby
language: ruby
cache: bundler
rvm:
  - 2.4.1
after_success:
  - export PRONTO_PULL_REQUEST_ID=${TRAVIS_PULL_REQUEST} && bundle exec pronto run -f github_pr

```

With the environment variable `TRAVIS_PULL_REQUEST` we will obtain the ID of the Pull Request being analyzed, then pronto will launch and only will check code differences against `origin/master`, not the full codebase.

This time we have configured the build to check style issues only when test build is successful but you can use many different [hooks](https://docs.travis-ci.com/user/customizing-the-build/).

Before running to Github to check our Pull Request we have to do one more thing. Pronto needs a specific token to be able to access our Github repository, to create it access your [github settings](https://github.com/settings/tokens) and generate a new token with only read access, it doesn't need anything else.

![settings](https://cdn-images-1.medium.com/max/1600/1*rxgTqAJej5DcYt1ynWurDQ.png)

Once you have created it, go to your Travis configuration and add the token as an environment variable name `PRONTO_GITHUB_ACCESS_TOKEN`

If everything went right you can create a new Pull Request with your changes and check that pronto makes his work.

[This](https://github.com/epergo/pronto_post/pull/1) would be the result with the previous example code:

## Conclusion

The landscape of tools at our service to check and improve our code is huge, from styling issues to security and complexity checks.

Here we have seen a little example of what it can be accomplished, but it can do a lot more, it depends on the necessities of every project and group of developers.

The important thing is that we checked our code against a set of rules of quality that allows us to spend time on what is important, our business logic.