Using Ruby style and formatting tools like Standard or rufo on legacy application is tricky. You make a small change to an existing file, run the linter to check your work, and–dang. So many style pre-existing style violations! Such noisy ensuing git commits! That’s why I really like Pronto–it only checks your specific changes, not the whole file, so you can keep changes in scope.
I’ve written in the past about automating code review locally with Pronto, and the mindset I like to adopt around code review (both as a reviewer and reviewee). In this article, I’ll take it one step further, and show how to elevate automated code review by integrating Pronto with a CI pipeline–specifically, GitHub Actions!
I’m assuming your project is already on GitHub. I recommend doing this work in a new branch, rather than pushing it up straight to your project’s default branch, so you can test the integration with some intentionally bad code.
Add a configuration file to tell GitHub Actions to scan code on each pull request. This is almost verbatim from the example provided in the Pronto README, but I’ve modified it to share the runners I use most, along with comments to help explain a few steps.
Put the file in the .github/workflows directory. You can name the file whatever you want, as long as it ends in .yml.
I like Standard (versus, say, straight-up Rubocop) because it’s an opinionated style guide, and I’m on-board with pretty much all of its opinions. Any style guide that steers you toward cleaner commits is a big winner in my book. I’ve also included Brakeman here because it’s simple to integrate and can find easy-to-miss security holes in your application. I recommend these as starting points regardless of your level of experience with Rails.
Now for the fun part: Let’s see the setup in action. To test the new GitHub Actions workflow, create a new temporary branch from the feature branch you used to add the workflow. (You can also totally use the same development branch if you’re comfortable using Git to clean up and force-push changes to your feature branch.) If you’re using Standard, intentionally bad indentation (three spaces instead of two, tabs instead of spaces) or using single quotes instead of double quotes are good test cases for this setup.
Push your branch up to GitHub, open a pull request, and give the workflow a few minutes to do its job. You should receive an email notifying you of success or failure, and each runner (in this case, Standard and Brakeman) will pass or fail the PR. But here’s my favorite part: Pronto reports each found violation as an in-line comment in your PR’s code!
From there, you can fix the violations (ideally using fixup commits that you can autosquash before merging), or use GitHub’s collaboration tools to discuss reported violations with teammates. Unfortunately, the github-actions bot isn’t yet smart enough to have a conversation with you.
With one file, this GitHub Actions and Pronto integration adds a nice safety net to any Rails application, to help protect against future bad code violations. Violations are reported in a way that’s just obtrusive enough for a developer to notice. Think of the integration as your super-detail-oriented robot teammate who’ll find those little style issues, so you can get them fixed before turning the review over to your human teammates.
There are many more Pronto runners you may wish to check out and add to your own setup. Thanks for reading!
If you liked my series on practical advice for adding reliable tests to your Rails apps, check out the expanded ebook version. Lots of additional, exclusive content and a complete sample Rails application.
Ruby on Rails news and tips, and other ideas and surprises from Aaron at Everyday Rails. Delivered to your inbox on no particular set schedule.