Use PR checks to lint your pull requests

As a team lead, you've probably been there – being the "bad guy" who constantly reminds developers to format their pull requests correctly. Here I'll show you how to use Sleuth to enforce PR standards without resorting to constant nagging, by using PR checks.

What's a PR check?

Pull Request checks are a form of guardrails. Guardrails are the implementation of agreements between engineers around how they work, what is acceptable, and what isn't.

You've seen PR checks before. When you go to one of your pull requests in GitHub for example, you'll see a number of checks at the bottom.

If you click on at the details of the highlighted failed PR check, you can see all the PR checks that the Sleuth team implemented as guardrails, and one of those checks failed because a commit message contains the word "WIP" - one of the things the team agrees not to do.

How PR checks using Automations work

One of the things our team agrees to do is to always include an issue key in PR titles for easy traceability. There's a PR check for that! This Automation from our Marketplace does exactly that, called PR title requires an issue key:

Once you have this installed, which by the way is just one click away, it'll catch a PR like this one that's missing an issue key from its title:

Track the impact of PR checks

If you implement PR checks using Sleuth Automations, you can track their impact. You can look at the automations you have installed, and what's cool is it doesn't just tell me that these things were installed, but it actually tells me if it's working.

So for example, the "PR title requires an issue key" check we talked about has resulted in a 100% improvement for our team.

How do we know that? If you click on the metrics tab, you can see the 100% number, as well as the calculation details. Before this Automation was installed, 184 out of all of our PRs had titles without issue keys, and since installed, only 3 out of 580 PRs had that problem.

Why use PR checks

PR checks are great because the developer who's doing the pull request is notified of violations of your PR standards immediately.

You don't need to have you, or another team lead or developer, send an annoying message saying "Hey, please fix this. Please fix the title that doesn't match our standards." Nobody wants to be that guy. Nobody wants to be the person that's nitpicking pull requests. Now you can use Sleuth to do it.

Think of it kind of like pull request linting.

Before we had code linters, we had developers go in and have to get everybody to use the same code format by bugging them in reviews and pair program or whatever you're doing.

Once we discovered linting, now we have a computer program that runs finds all the problems, tells the person who made the problem about the problem so they can fix the problem, and now no one else needs to tell them about the problem.

The point is to use a tool to do the annoying tedious bugging nagging work so that you can get back to focusing on the actual important stuff.

Where to find PR checks

Browse our Automations Marketplace for all the PR checks we have available. We're adding several Automations each week, including PR checks, so if you don't find what you're looking for, feel free to reach out!