Commit Message Lint – Reinforce Your Commits With Git hooks

“Workflow and usability are not afterthoughts; they impact the core of any project and dictate how it should be engineered ” – Ryan Holmes

Over 40 million developers use GitHub together to host and review code and some 100 million projects have been managed on it till date.

It provides a proven way to intercept different DevOps phases related to your code and apply various checks. It enables you to perform linting checks, static code analysis, enforce commit strategies, and regulate pull requests. And these are some common actions. Github provides a variety of events which could be captured and acted upon. 

Github apps is a proven way of implementing and improving your workflow effectively. We leverage this powerful feature to regulate our Github commit messages format and pull request titles. Let’s take a look at the genesis of the idea, it’s execution and how to utilise Github for the same.

Problem Statement

As with most of the project these days, we follow Agile methodology for our projects. And the tool which helps us keep track of user stories and deliveries is JIRA. To keep the quality in check, we follow code review processes with the help of Github pull requests (referred to as PR from here on). This was going ok for us for a while.

Keeping Track of PR

After a while, with the increase in team size and deliverables, it became difficult for us to keep track of PRs themselves. There would be multiple developers working in parallel, some of them on different parts of a larger feature. This meant that there would be a number of PRs opened and waiting for merging.

To ease the process for the reviewers a bit, we integrated JIRA with Github workflow. And we asked the developers to put the JIRA ID in the commit ID and the PR title so that workflow would recognise the ticket to which the PR belongs. This helped us with two things –

1. The Github workflow would recognise tickets in commits and PRs and process them accordingly.
2. The reviewers would be able to recognise the PR, thereby prioritising as per the business and technical needs.

The process surely looked promising from the outside. But soon we realised that there was a very basic flaw in this process. It relied on the developers to provide a valid Github commit messages format and PR title. And that was a problem for us. We wanted the developers to enter the messages and title in a very specific format.

Solution

The first thing which came to our mind was git hooks. Those would be a quick solution to fix the  Github commit messages format issues. But hooks have some inherent problems because of their local installation nature:

  They have to be installed on the developer’s machine.

• The onus relies on the developer to make sure they have installed the hooks.
• Every time a new developer joins, this becomes a part of their onboarding process.
• It’s difficult to update hooks, as they are not centralised.
• Adding a new capability into the hooks would mean going through the whole cycle from the start.
• Anybody can alter their local copy.

They have also had limitations in terms of actions they can perform.

• Their scope is limited to local repository.
• They cannot be used for continuous integration workflows.

With all these restrictions, we can safely say that hooks are more of a developer tool. But need something to enforce a strategy, or we can say a policy.

Enter Github Apps!!

Github apps provide a simple and straightforward mechanism to enforce and manage development policies. They are also recommended by Github itself because of the access and control they provide. It’s beneficial to use Github apps as:

• They provide granular permissions
• Access to repository events like PR creation, issue creation, etc.
• Access to code itself, enabling us to perform tasks like linting, static code reviews, etc.
• Central installation into the repository, providing more control.
• Easy to track app execution and issue from Github itself.

So Github app is what we used to solve our problem.

Commit Message Lint

As mentioned above, our requirement was to enforce particular Github commit messages format and PR titles. So we built a Github app which would do this for us, as soon as a PR was generated.

Github Apps gave us the ability to perform multiple checks with just one codebase. And this app was totally in our control. All we did was install the app in our repositories. From then on it would start appearing in PR checks, whenever a new PR was raised.

PR Page – Successful check

PR Checks Page – Successful check

Flow diagram

Let’s take a look at the workflow once we have this app installed in our repository.

Features

We saw the core purpose of building the app. Let’s take a look at some key features:

Configuration for formats

The App allows you to configure separate formats which should be followed for PR titles and commit messages. These configurations need to be kept in your repository itself, providing the flexibility of having different formats per repository. And since they are present in the repository, they can be altered at any point, providing dynamic nature.

Look at this tutorial on how to configure the formats in your repository.

Pull Request Title format check

The app will check for the PR title format:

1. On the creation of PR: As soon as a PR is created, a check will be created in the checks section of PR. This will show the result of PR title validation in the form of success/failure.
2. Re-run check: Github allows users to re-run a particular check, for example, once the issues have been resolved. So in our case, if someone has updated the PR title as per the required Github commit messages format, they can re-run an existing check and view the results.

Github commit messages format check

Similar to PR title check, the app checks for the format in  Github commit messages format. One PR can have multiple commits and all the commit messages are checked. Similar to PR title, commit messages are checked:

1. On PR creation: When a new PR is opened.
2. Re-run check: When the re-run check button is clicked.

Merging the PR

The PR ownership still resides with the reviewer. The app does not enforce or block merging the PR. Based on the status of the check the reviewer has full discretion on whether to go ahead with the merge of asking the developer to make the changes.

Benefits we realised

So we developed the app, registered it on Github and published on Github marketplace.  That’s all good. But what are the benefits we realised? Let’s take a look at some of them:

Setting up the app:

• Setup the checks from Github in any repository, providing central control.

Configuration:

• Easily configure the formats and update them as and when required.

Enforcing the format:

• The reviewer does not have to worry about the PR title or commit message. They would just look at the status of the check and make a decision.
• Speeds up the review process.
• Control resides at the repo level rather than with developers and reviewers.
• Easy to get developers on board with no additional setup (like git hooks).

Improving the process:

• With the automated check, it’s easier to follow and enforce the process.
• Setting up the process for new projects and repository is easy.
• Centrally manage and review the process.

Workflow automation:

• With the enforcement of the process and required Github commit messages format, integration with JIRA becomes easier and flawless.
• The overall workflow automation improves with lesser loopholes.

One less thing to worry about:

• An important benefit which usually gets overlooked is that reviewers have one less thing to worry about. They can rely on the Github app to review the formats and let them know the results.

These were some of the benefits along with the most important one, integration with JIRA and automation workflow.

One Last Thing

It sounds exciting to have an automated workflow in your project. But it’s when you try to implement it, you realise the difficulties involved. With manual controls involved at various places, your dream of a perfect workflow can go down the hill gradually.

You need to only focus on the business logic and not the automation process. Let Github app worry about your process and enforce the formats. This assists the developers to also improve their development habits.

Systango team always follow the best practices in terms of project execution, right from the initiation of the project until the last check. Our engineers have already delivered numerous apps using different technologies and tools. If you wish to leverage managing functionality for deeper customer engagement, give us a call today.