Automate your pull requests checklist

Recently, a friend shared the pull request checklist below with me. I didn’t know whether to laugh or cry. How could someone endure such a long list of boxes to tick?

Why pull request checklists are a pain

Such long checklists are either built incrementally each time an issue occurs during the integration of pull requests, or as a knee-jerk reaction after a frustrated developers fixed one too many issues after a bad merge.

They are a lazy way to attempt to fix the problem and they are very problematic:

1. Let’s face it, they are frustratingly annoying to go through.
2. They waste developers’ time as most of those checks can be automated.
3. The longer the checklist, the less likely is will be followed with high quality.
4. It creates a culture problem: if something goes wrong and was not part of the checklist, it’s not my fault.

I am not saying you absolutely should not have checklists but they should be short, focused on quick useful reminders and things very tough to automate (for now!) such as accessbility testing. If anything you should always critically look at this checklist and aggressively try to automate it out so it’s done by default and saves developers time and cognitive load.

Automating integration checks in your CI pipeline

The best place to start automating your pull requests validation checklist is your Continuous Integration (CI) pipeline. In Simple Frontend docs I showed examples how to validate formatting here and linting here.

The recipe is quite simple:

1. You clone your project.
2. You install dependencies.
3. You run the check command you were asking the developer to run locally inside your CI pipeline.
4. If the command fails, you fail the integration build, else you mark it as successful.

You can automate a lot here, formatting, linting and unit tests of course but also test coverage, code organization, code analysis, missing environment variables and even do static analysis to decide on potential follow up tasks needed such as documentation or migrations.

Reducing the feedback loop further

While it’s nice to no longer have to have to check and validate yourself most of your pull requests integrations, it can still be frustrating to see a pull request pipeline fail because of formatting or linting issues.

That’s where you can introduce tools to validate those changes earlier in the development workflow, either at commit or branch push time. In this case you only want the validation checks to take seconds at most to not disrupt the developers flow. A good way to ensure a short validation time is for example to only run those checks on changed files.

I recommend a pre-push hook as it’s less distracting than commits and I want to be able to have “diirty” commits I will squash later. I really like lefthook with pre-push as it’s simple and efficient. If even offers utilities such as:

• {staged_files} - staged files which you try to commit.
• {push_files} - files that are committed but not pushed.

Making it easy to create a pre-push hook like this:

pre-push:
  commands:
    eslint:
      glob: "*.{js,ts,jsx,tsx}"
      run: yarn eslint {push_files}

Another popular solution for pre-commit hooks is lint-staged which will run tasks about your staged git files but I find it less powerful and more distracting than leftook.

Regain happiness and start automating your pull requests checklist, you will thank yourself later!