Automate Code Reviews on Github Using a Chatbot

Updated on December 9, 2024

Automate Code Reviews on Github using a Chatbot

 

‘Danger’ to the rescue

Danger runs during your CI process, and gives teams the chance to automate common code review chores. This provides another logical step in your build and through this Danger can help lint your rote tasks in daily code review. You can use Danger to codify your teams norms, thus leaving humans to think about harder problems. She does this by leaving messages inside your PRs based on rules that you create with the Ruby scripting language. Over time, as rules are adhered to, the message is amended to reflect the current state of the code review. 

 

Adding it to your CI workflow

We use Bitrise in our mobile SDK projects. It’s a Continuous Integration and Continuous Delivery service for mobile Apps. If you are using a different CI service then, you can check this guide on how you can integrate Danger with that service. There is a detailed blog post on integrating Danger with Bitrise. I will summarise it in five points:

• Install bundler, create a Gemfile and add the Danger gem to the Gemfile.
• Create a Dangerfile for your project.
• Create a bot user on Github and a Personal Access Token for the bot.
• Then add the generated token on Bitrise.
• Add a script step in the project’s workflow. That’s it! ?

Rules which we can Automate

• It returns almost all the information you see on GitHub’s pull request webpage like title, description, assignee, reviewers, labels etc.
• There’s one more API to fetch a list of changed files. For each file, it will return the name of the file, the number of additions to the file, the number of deletions to the file.
• We don’t have to use this APIs as we will be using Danger which gives us an easy way to interact with this data.

List of Rules we Automated

When we were adding danger to our repository we looked at our requirements and, some of the other projects which were using Danger. Below are some of the checks that we have in our projects.

Bonus: Do you want to build chatbot without any coding?

Learn more about Chatbot Builder

• Warn if it’s a big PR: We tend to make this mistake of pushing a lot of changes in one PR. Reviewing such PRs is a difficult task. We added a warning which shows up when the number of lines updated in a PR is more than 500.
• Encourage pull request descriptions: Sometimes developers think that description is not necessary or we forget to add. Even though you mentioned the issue number, a brief description always helps and gives a context to the pull request. To see if the description is empty or not we can check the body length:

• Check if the tests are missing: We all know tests are important and, we tend to skip this step. Whenever we do any modification in the source code, we should add tests if possible. So, now it warns if there are any changes in the source code and, the tests folder is not modified which means new tests are missing.
• Update Changelog: Added a new feature or fixed a bug – update the Changelog with the details. We made it mandatory to add a Changelog entry if the change is nontrivial. If the Changelog is not updated and pull request is not marked as trivial, then our CI fails the build. Now, we don’t have to keep a track whether the Changelog was not updated.
• Encourage rebase not merge commits: As the project grows it’s always recommended that we should avoid ‘merge’ commits so that the project has a clean history. We prefer using rebase instead of merging different branches. We can add a check for messages of this format: “Merge branch ‘master’” to avoid the merge commits.

Where to go next