Effortless Code Conventions Review for Pull Request Changes

#ruby #ci #github #codereview

Reliably arranged source code helps hackability. You can filter code speedier if its organizing is predictable.

Photo by chuttersnap on Unsplash

To fight with non-consistent source code formatting there are static analysis tools such as RuboCop .

We decided to share code formatting feedback directly on GitHub by commenting Pull Requests changes.

There is a suitable tool for this job - pronto . With help of *CI *(in our case that’s CircleCI ) we run it for each Pull Request.

Our CircleCI 2.0 configuration to run pronto #

**NOTE: **In order to reduce mess with dependencies we put all our linters and pronto into separate Gemfile.tools.

# .circleci/config.yml
version: 2
jobs:
  lint:
    environment:
      - BUNDLE_GEMFILE: Gemfile.tools
    docker:
      # specify the version you desire here
      - image: circleci/ruby:2.4.2-stretch-node-browsers
        environment:
          RAILS_ENV: test
          RACK_ENV: test

    working_directory: ~/repo

    steps:
      - checkout
      - restore_cache:
          keys:
          - v1-tools-dependencies-{{ checksum "Gemfile.tools.lock" }}
          # fallback to using the latest cache if no exact match is found
          - v1-tools-dependencies-

      - run:
          name: install cmake
          command: |
            sudo apt-get install cmake            
      - run:
          name: install dependencies
          command: |
            bundle check --path vendor/bundle || bundle install --jobs=4 --retry=3 --path vendor/bundle            
      - save_cache:
          paths:
            - ./vendor/bundle
          key: v1-tools-dependencies-{{ checksum "Gemfile.tools.lock" }}


      - run:
          name: run source code analysis
          command: |
            bundle exec pronto run -c origin/master -f github_status -f github_pr_review --exit-code            
      - store_artifacts:
          path: ./tmp

workflows:
  version: 2
  release:
    jobs:
      - lint:
# Run lint after tests
#          requires:
#            - test

source 'https://rubygems.org'

git_source(:github) do |repo_name|
  repo_name = "#{repo_name}/#{repo_name}" unless repo_name.include?("/")
  "https://github.com/#{repo_name}.git"
end

gem 'pronto'
gem 'oj'
gem 'pronto-rubocop', require: false
gem 'pronto-scss', require: false
gem 'pronto-eslint', require: false
gem 'pronto-brakeman', require: false
gem 'pronto-rails_best_practices', require: false

Finally, you need to add PRONTO_GITHUB_ACCESS_TOKEN. You could obtain your PERSONAL GITHUB ACCESS TOKEN by following this instruction and check environment variable on CircleCI to add it to the project.

Summary #

There are similar ready SASS solutions to help you with reducing the amount of waste:

But they are not free and most of them are solve only specific problems.

With pronto, you have more options to customize by:

  • setup specific code analyzers for the different problems

  • easier support rules to follow company conventions

  • store rules in the repository with project source code

Let’s remove the waste of time for trivial problems and spend it on codding!

Get More #

Contact us to find out more about how we work. We’re excited to help you — as always, we’d love to hear what you think!

Paul Keen is an Open Source Contributor and a Chief Technology Officer at JetThoughts . Follow him on LinkedIn or GitHub .

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories .

Comments