Github PRs to Slack notifications

Image from http://bit.ly/2QHGvOP

Behind the story

I am currently employed to an organization where whenever a change is made for either a bug fix or new features get implemented, all the merges should follow as

1. There should be someone to review your code.
2. Your code gets merged when the PR gets approval.

So far so good. But the problem is somewhere else. Whenever we create a PR, we need to send a link to the guy who is supposed to review the code. After he confirms that he approved the PR, we again need to send the link to the DevOps guys. They then merge the PR. The problem is to give them the PR links manually. We have to send the link twice. So, I wrote a bash script, where I will just give it a link & it’ll mention the channel in a slack group. Then one of our colleagues told me to write a bot kinda thing. After that, I thought of writing a bot that will listen to GitHub PRs and send messages accordingly.

What does this do?

It’s a flask application. It starts a server that listens for incoming webhooks from GitHub and sends the corresponding messages based on the types or webhook it receives.

How to install it?

Let’s start.

• Firstly, clone the application from https://github.com/ssi-anik/peer-pressure
• copy the configuration.yaml.example to configuration.yaml (it’s yaml not yml)
• copy the docker-compose.yml.example to docker-compose.yml — If you want to run your application through docker.
• Make the required changes to your docker-compose.yml and configuration.yaml file.
• docker-compose up -d --build to start your application.

Explanation of configuration.yaml

• app-name is the name of your application.
• app-env is the environment your app should run. development | production | staging
• host If you’re running in a docker container, it’s good to set 0.0.0.0
• port The port you want your application to listen to. The Dockerfile exposes port 80. So, if you want to run in another port, change Dockerfile and docker-compose.yml as well.
• debug set a boolean value to enable/disable debug mode.
• secret-key This key’s value determines where to check for the signature it receives from GitHub or not. If you set the key, it’ll check the X-Hub-Signature received with the webhook request. If you decline to do so, don’t put the key in your configuration file.
• webhook-path a custom path for your webhook. If you want to make your webhook listener be on my-webhook set it to that key. Default is webhook
• webhook-method This key sets the HTTP verb for your webhook-path. Default is POST. It can also receive multiple verbs. Set as an array to it. Though it will always be POST.
• notification-medium Keep it as it is. For now, it’ll only send notifications to slack. Unsupported mediums will raise an exception.
• slack-url URL for the Slack webhook. Get to know how to add your slack webhook from HERE.
• slack-channel The channel that should receive the GitHub’s PR events.
• slack-username Set the username that will be shown when a message is sent.
• slack-emoji Set an emoji for the username.

Configuring messages & usernames

All your users from GitHub should have a slack account. Under users.slack on the left side, you should put your Github's username, and on the right side, you should put the slack user_id. Keep a note that the slack user_id is not just a name you type in channels. It’s something that starts with U or W. Get your ids from HERE or google to get all the ids with API.

Now, on the message part, the following events are sent from GitHub and you can send custom messages based on the events

• opened When a PR is opened.
• commented When someone comments from the PR review section.
• assigned If someone adds people to the assignees on a PR.
• labeled If someone adds labels to the PR.
• review_requested If someone asks someone else to review the PR.
• review_request_removed If someone is removed from the PR reviewer group.
• approved If the PR gets approved.
• changes_requested If the PR is reviewed with changes requested.
• merged When the PR gets merged.
• closed If the PR is closed without getting merged.

For all the above actions, you can set custom messages as populated on the configuration file by default. The following keys will be available for each message.

• number — The PR number.
• title — The title of the PR.
• repo — The repository which got the PR.
• by — The user who initiated the PR.
• base — Base repository:branch label.
• head — From repository:branch label.
• assignees — The people who got assigned for the PR.
• requested_reviewers — The people who got assigned to review the PR.
• actor — The actions get performed by.
• labels — It contains the labels for the PR.
• merged_by — The PR was merged by (value on merged event).
• merged_at — When the PR is merged at (value on merged event).
• comment — When someone comments from the review section (value on commented event).
• removed_reviewer — When someone is removed as a reviewer (value on review_request_removed event).
• url — Url of the PR.

So, you can change your messages. When you use these variables, make sure to put curly braces around these variables like {by} — {from}.

How about limiting events?

Yes, you can also limit the number of events to push to your slack channel. Like, you want to notify your channel only on opened and approved and merged event. You have to remove the unwanted events fromlisten-events. If you don’t set the listen-events key, then it’ll shoot all the event messages to your channel. If you set keys for this key which is invalid, it’ll do nothing.

Notes

• If you set a secret-key and it doesn’t match the GitHub’s X-Hub-Signature value, it’ll then 401.
• It only works for the application/json form.
• For GitHub events, it’ll return successful status code only for ‘pull_request’, ‘pull_request_review’, ‘ping’. All other events are simply discarded with 401.