THthunderbong·Mar 6, 2024Submission
Pronto: Quick automated code review of your changes
1 points · Open discussionprontolabs
pronto
Ruby2013–2024
prontolabs / pronto
pronto
Quick automated code review of your changes
4Distinct people
8Mentions
1Explicit recommenders
2.7KGitHub stars
What to know before exploring
What it is
Quick automated code review of your changes
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
I highly recommend it's use with pronto. We run Rubocop, Rails Best Practice and Brakeman against every commit by calling pronto from CircleCI. https://github.com/mmozuras/pronto
dankohn1 used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year8 dated mentions
Observed mentions: 2013-10-25 16:37:08 UTC to 2024-03-06 10:56:44 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
8 sourcesThoroughly agree that this is a human problem, but I think there are some amazing automated fixes for it, by incorporating code checkers into the continuous integration pipeline. Take a look at how the CII best practices badgeapp [0] uses pronto [1] to run rubocop [2] automatically for free via CircleCI [3] and surface those results via the Github Status API and email.
The whole point is to avoid having to manually complain in a code review. Instead, code reviews become a much higher level exercise discussing proper APIs and code structuring, not sphaghetti issues.
[0] https://github.com/linuxfoundation/cii-best-practices-badge/...
[1] https://github.com/mmozuras/pronto
[2] https://github.com/bbatsov/rubocop
[3] https://circleci.com/
In What to Do When Your Colleague Creates Spaghetti CodeWe try to solve it in a couple of ways:
* Enable smaller PRs. Reviewing 50-150 lines of code is much less daunting. This can be done by using tools like feature flags, AB tests, github/scientist etc.
* Ask/communicate about the quality of PRs. Like: splitting big ones into multiple,writing good descriptions, including the problem and screenshots.
* Automate the trivial parts. We use Pronto (disclaimer: I'm the author - https://github.com/mmozuras/pronto), but there are other tools/services that can help achieve the same result.
In Ask HN: How do you review code?We're not nearly at Stripe's scale, but my startup (Spreemo) has achieved pretty amazing parallelism using the commercial SaaS CircleCI. We have 3907 expects across 372 RSpec and Cucumber files. Our tests complete in ~14 minutes when run across 8 containers.
One of the great strengths for CircleCI is that they auto-discover our test types, calculate how long each file takes to run, and then auto-allocate the files in future runs to try to equalize the run times across containers. The only effort we had to do was split up our slowest test file when we found that it was taking longer to complete than a combination of files on the other machines.
I also like that I can run pronto https://github.com/mmozuras/pronto to post Rubocop, Rails Best Practices, and Brakeman errors as comments on Github.
In Running three hours of Ruby tests in under three minutesI highly recommend it's use with pronto. We run Rubocop, Rails Best Practice and Brakeman against every commit by calling pronto from CircleCI.
https://github.com/mmozuras/pronto
In RuboCop – A Ruby static code analyzerTake a look at https://github.com/mmozuras/pronto - does the same, has many adapters.
In Hound: A service that comments on Ruby style violations in GitHub pull requestsCurrently, my main side-project is Pronto, quick automated code-review tool: https://github.com/mmozuras/pronto
Intend to make a SaaS from its current library form, at some point, also.
A couple of others on the back burner.
In Ask HN: What kind of side projects are you working on?Show HN: Pronto - quick automated code review of your branches and pull requests
6 points · Open discussion