Pull Request Notification Automation

TL;DR Recently I've released a new version of my GitHub Pull Request Notification Bot and enabled it for the internal tech team in the company. The project manages Slack messages based on the GitHub Pull Request events. Over the last two weeks, it has worked perfectly for our team and saved some time for us. In this article, I will share the details about the project and how it works. Like it? Let's dive into the details. Motivation Automate or do things manually? The answer is always "Automate!", even if it is a small task. In my team, we emphasize agile development and frequent releases. Code reviews are a key part of our workflow, and we actively use Slack for communication. As a result, it has become a daily routine for the author of a pull request (PR) to manually notify the team in a Slack channel and keep the message updated so others can easily see whether the PR needs review or has already been merged or closed. So, I spent some time over the weekend building a simple application to automate it. You might wonder why we don’t just use GitHub’s Slack integration. The reason is straightforward: it generates excessive noise by sending separate messages for every event. There’s no way to update messages, format them properly, or tag users, making it less effective for our needs. Basic concept and functionality In general, the application is a simple web server that listens to the GitHub webhooks posts messages to Slack, and creates as little noise as possible. At the same time, it must be flexible and configurable so every team can set up the application according to their needs. Functionality: Post a message to the Slack channel when a new PR is created. Update message in the Slack channel when PR is merged or closed. Delete message in the Slack channel when PR is moved from Ready for Review to Draft. Post message to the Slack channel when PR is moved from Draft to Ready for Review. Tag users or groups in the Slack message. Multiple Slack channels. Multiple GitHub repositories. (Optional) Reactions to the messages in the Slack channel when the PR is merged or closed. Application Details As you can see on the schema above, the application requires having an SQLite database. You might ask "Why do you need a database?". The answer is "To keep Slack message ID for future updates". Another reason to have a database is to store the configuration for each repository and Slack channel. Configuration Take a look at the configuration item +------------------+---------------+--------------------------------------+ | Repository | Slack Channel | Mentions | +------------------+---------------+--------------------------------------+ | owner/repository | C12312312111 | , | +------------------+---------------+--------------------------------------+ As you can see you can set up channel and mentions for each repository. This is quite useful when you have multiple teams, channels, and repositories. To manage the configuration three cli commands were created: gsm:write - to create or update the configuration to the database. The first argument (owner/repository) is used as an identifier. Example: php bin/console gsm:write owner/repository SLACK_CHANNEL_ID ',' gsm:list - to list the configuration from the database. Example: php bin/console gsm:list gsm:remove - to remove the configuration from the database. Example: php bin/console gsm:remove owner/repository Note: the gsm abbreviation in the command stands for GitHub Slack Mapping. In addition, via environment variables, you can enable/disable reactions and set the emojis for the reactions. Please, visit the configuration documentation for more details. GitHub Webhook To receive the GitHub events you need to set up the webhook in the GitHub repository settings. I described the GitHub Webhook registration process in the GitHub webhook registration article. Please note, that there is no need to send all the events, "Pull request" events are enough. The application will filter out all unnecessary events. Slack Integration To post messages to the Slack channel you need to create a Slack bot and get the token. The token should be set as an environment variable. You can find the detailed instructions here. Use cases Use case 1: A new PR is created. The application posts a message to the Slack channel. The application stores the message ID in the database and relates it to the repository and PR. Use case 2: A new draft PR is created. No action is taken. Use case 3: PR is moved from "Draft" to "Ready for Review" state. The application posts a message to the Slack channel. The application stores the message ID in the database and relates it to the repository and PR. Use case 4: PR is moved from "Ready for Review" to "Draft" st

Mar 14, 2025 - 16:15

TL;DR

Recently I've released a new version of my GitHub Pull Request Notification Bot and enabled it for the internal tech team in the company. The project manages Slack messages based on the GitHub Pull Request events. Over the last two weeks, it has worked perfectly for our team and saved some time for us.

In this article, I will share the details about the project and how it works.

Like it? Let's dive into the details.

Motivation

Automate or do things manually? The answer is always "Automate!", even if it is a small task.

In my team, we emphasize agile development and frequent releases. Code reviews are a key part of our workflow, and we actively use Slack for communication. As a result, it has become a daily routine for the author of a pull request (PR) to manually notify the team in a Slack channel and keep the message updated so others can easily see whether the PR needs review or has already been merged or closed.

So, I spent some time over the weekend building a simple application to automate it.

You might wonder why we don’t just use GitHub’s Slack integration. The reason is straightforward: it generates excessive noise by sending separate messages for every event. There’s no way to update messages, format them properly, or tag users, making it less effective for our needs.

Basic concept and functionality

In general, the application is a simple web server that listens to the GitHub webhooks posts messages to Slack, and creates as little noise as possible. At the same time, it must be flexible and configurable so every team can set up the application according to their needs.

Functionality:

Post a message to the Slack channel when a new PR is created.
Update message in the Slack channel when PR is merged or closed.
Delete message in the Slack channel when PR is moved from Ready for Review to Draft.
Post message to the Slack channel when PR is moved from Draft to Ready for Review.
Tag users or groups in the Slack message.
Multiple Slack channels.
Multiple GitHub repositories.
(Optional) Reactions to the messages in the Slack channel when the PR is merged or closed.

Application Details

As you can see on the schema above, the application requires having an SQLite database. You might ask "Why do you need a database?". The answer is "To keep Slack message ID for future updates". Another reason to have a database is to store the configuration for each repository and Slack channel.

Configuration

Take a look at the configuration item

+------------------+---------------+--------------------------------------+
| Repository       | Slack Channel | Mentions                             |
+------------------+---------------+--------------------------------------+
| owner/repository | C12312312111  | <@U08ENEE1ZPW>,  |
+------------------+---------------+--------------------------------------+

As you can see you can set up channel and mentions for each repository. This is quite useful when you have multiple teams, channels, and repositories.

To manage the configuration three cli commands were created:

gsm:write - to create or update the configuration to the database. The first argument (owner/repository) is used as an identifier. Example:
```
    php bin/console gsm:write owner/repository SLACK_CHANNEL_ID '<@USERID>,'
```
gsm:list - to list the configuration from the database. Example:
```
    php bin/console gsm:list
```
gsm:remove - to remove the configuration from the database. Example:
```
    php bin/console gsm:remove owner/repository
```

Note: the gsm abbreviation in the command stands for GitHub Slack Mapping.

In addition, via environment variables, you can enable/disable reactions and set the emojis for the reactions. Please, visit the configuration documentation for more details.

GitHub Webhook

To receive the GitHub events you need to set up the webhook in the GitHub repository settings. I described the GitHub Webhook registration process in the GitHub webhook registration article. Please note, that there is no need to send all the events, "Pull request" events are enough. The application will filter out all unnecessary events.

Slack Integration

To post messages to the Slack channel you need to create a Slack bot and get the token. The token should be set as an environment variable. You can find the detailed instructions here.

Use cases

Use case 1: A new PR is created.

The application posts a message to the Slack channel.
The application stores the message ID in the database and relates it to the repository and PR.

Use case 2: A new draft PR is created.

No action is taken.

Use case 3: PR is moved from "Draft" to "Ready for Review" state.

The application posts a message to the Slack channel.
The application stores the message ID in the database and relates it to the repository and PR.

Use case 4: PR is moved from "Ready for Review" to "Draft" state.

The application deletes the message in the Slack channel.
The application removes the message ID from the database.

Use case 5: PR is merged.

The application updates the message in the Slack channel with the "[Merged]" message prefix.
(optional) The application adds a reaction to the message.

Use case 6: PR is closed.

The application updates the message in the Slack channel with the "[Closed]" message prefix.
(optional) The application adds a reaction to the message.

How is it used in our team?

In my team, we have one team which consists of frontend and backend developers. Frontend developers work on the React application using a separate repository and backend developers work on the API application using another repository. For the sake of limiting the number of channels, we decided to use one channel for both repositories and tag the team members who maintain the repository.

After the bot application was set up I created configuration items in the database using the gsm:write command. Also, I registered a webhook in both repositories and invited the bot to the channel.

As a result when the frontend app repository has opened PR the message tags @fronend developers and if a PR is created in api app repository the @backend developers are tagged.

And this is the result overview of what we have now:

Conclusion

The application is super simple. It automated everyday routines and made team communication more effective.

If you found this project useful, please give it a star on GitHub and share it with your friends.

Please note that it's still under development, and I'm open to any suggestions or contributions.

Check out more articles on my blog.