Photo by Sanwal Deen

As our engineering team continues to grow it’s becoming difficult to keep track of all the changes that we’re introducing to our codebase every day.

We’d like to find an automated way to categorize the changes in each pull request based on the files that they touch.

Let’s try auto-labeling pull requests that match the following criteria:

Dependencies have changed e.g. gems or node modules

Database migrations have changed

Styleguides for Ruby, JavaScript, or SCSS have changed

First let’s define our labels

We’ll use dependency, migration, and styleguide as our pull request labels. We just need to define a list of file patterns that match them.

Next let’s introduce a labeler

We’ll need something that accepts a list of the files changed in a pull request and returns an array of all matching labels.

Let’s use Ruby’s built-in File#fnmatch to perform the glob pattern matching.

Now let’s actually update our pull request labels

We’re using GitHub to manage our pull requests so let’s use the octokit gem to communicate with their API. We’ll only need to use these two methods:

compare to fetch a diff of all the files changed in a pull request

to fetch a diff of all the files changed in a pull request add_labels_to_an_issue to actually update pull request labels

Finally let’s tie it all together in a simple webserver

Let’s create a sinatra app with an endpoint to receive webhook events from GitHub. First let’s generate a Gemfile and define our dependencies.

Now let’s create a config.ru file and configure our webserver. This server process can be started by simply calling bundle exec rackup.

GitHub allows us to configure webhooks organization wide so that all of our repositories get this auto-labeling behavior. Let’s configure a new webhook that only listens for pull request events.

Success! Now all of our pull requests get auto-labeled anytime we push changes to files that match our label definitions.

Taking it a step further with the owners gem

As we continued to enhance and iterate on this concept we’ve found additional uses for labeling files in general. We’ve wrapped these enhancements in the owners gem which includes features like:

A command line interface so we can match labels against files locally

OWNERS files so that our label patterns can live within our repositories

Matching files with regular expressions instead of simple glob patterns

Debugging info so we can inspect which patterns matched specific files

Finding files that don’t match any of our defined label patterns

Let’s update our pull request auto-labeler to use the owners gem instead!

Knowing who owns a project or section of a code base is very helpful when asking questions or requesting feedback. The owners gem allows developers to define OWNERS files throughout their repository to provide a human and machine readable way to determine who the maintainers are for specific files of code.

These OWNERS files can be used to:

Define file patterns for auto-labeling pull requests

Find the right people to ask when you have questions

Request approval from the appropriate people in pull requests

Notify maintainers when changes occur to the files that they care about

Try it out in your own projects! What other uses can you find for OWNERS?

Our engineering team is still growing! We’re hiring engineers in our San Francisco and Columbus, OH offices. See our careers page to learn more. We look forward to hearing from you!