A Ruby static code analyzer, based on the community Ruby style guide.
I think, many are familiar with the Hound service for automatic code check. When you create a new Pull Request on GitHub, Hound launches a checkup of your code based on such solutions as rubocop, haml-lint or scss-lint. If any problems pop up during the checkup process, Hound will report on it by adding the corresponding commentary to your Pull Request. It is a great work tool, but you know what they say – all good things come with a price.
Hound landing page
Cloud Continuous Integration service. Unlimited parallelism.
Not every company is ready to pay this much money, so I decided to take a different approach. I used the pronto library as the basis since its out-of-box version does everything Hound can. The only thing left is integrating pronto with Vexor. The following is a step-by-step manual for what has to be done.
First you go to GitHub and generate a personal token.
Creating personal token at GitHub
Then you add two environment variables in the properties of your Vexor project.
Adding environment variables in Vexor project
Then you add pronto and several of its plug-ins to you project’s Gemfile. To view the list of available plug-ins, click here.
group :test do gem 'pronto' gem 'pronto-brakeman', require: false gem 'pronto-coffeelint', require: false gem 'pronto-fasterer', require: false gem 'pronto-flay', require: false gem 'pronto-haml', require: false gem 'pronto-jshint', require: false gem 'pronto-rails_best_practices', require: false gem 'pronto-reek', require: false gem 'pronto-rubocop', require: false gem 'pronto-scss', require: false end
Launching pronto requires creating a bin/pronto file:
#!/usr/bin/env ruby require 'bundler/setup' require 'pronto' require 'pronto/cli' begin Pronto::CLI.start rescue Octokit::NotFound puts 'Pull Request Not Found' end
And giving it chmod access:
$ chmod +x bin/pronto
Now all you need is to add several instructions to .vexor.yml:
language: ruby script: - git remote set-branches origin '*' - git fetch - git checkout $CI_BRANCH - bin/pronto run -f github_pr -c $DEFAULT_BRANCH - bundle exec rake
And that’s it, it is now ready for checkups.
Some would object: why would you need all this when you have overcommit? New project developers often forget to tune overcommit, and this is only found out several days later when another developer isn’t able to send the changes he made to the server. To exclude situations like that, I recommend using these tools together.
P.S. I’d like to thank Sasha Kirillov for his help in integrating pronto with Vexor.
In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day. There are a lot of different continious integration solutions with strong and weak sides.
Take part in the survey of our portal. Which Continuous integration system do you use?