Robot reviewing DANGERous Pull Request

Zahid Rasheed
3 min readMay 11, 2021

I would like to share how we have used Danger to ensure few common rules for a Pull request.

Danger helps customising the Github workflow for pull requests. There are so many ways you can use it, I can’t just put all of them here in one article. But what I can do is, share how we are using it : )

Let’s start with the integration.

Note: Danger has support for many languages from swift, kotlin, ruby to python and more. I decided to use Ruby as it is kind of default and also this is not something we update on daily basis. But you can try kotlin for Android and swift for ios etc…

Follow this simple guide to get started with danger

Now let’s look at use cases….

Changelog:

There are many ways you can generate changelog for your upcoming release candidate. How we were doing it; by going through git logs and finding all jira tickets that were merged to develop from a…b 🤮🤮🤮

A bit of help was, this command:

git log COMMIT-ID..HEAD — pretty=”format:%s” — first-parent

But again this was a terrible way to get all changes into a changelog and there was still a chance that you will add misleading logs, comments, etc.

So we decided to try Changelog. Not a rocket science, but how to make sure that people don’t forget to update changelog with every PR? Manually checking in every PR but what else? Here comes Danger to rescue:

if !git.modified_files.include?(“CHANGELOG.md”)
warn(“📋 Please include a CHANGELOG entry. You can find it at [CHANGELOG.md](https://github.com/PATH-TO-CHANGELOG-FILE)")
end

Big PRs:

We usually discourage super big PRs. Add a warning if PR is too big and recommend splitting into multiple small PRs?

message “😱 This PR is changing more than 500 lines of code. May be split into smaller PRs?” if git.lines_of_code > 500

PR Description:

A PR should have a summary of what is changed, as PR description. Show a warning if it is missing or too small?

warn(“📝 Please provide a summary in the Pull Request description.”) if github.pr_body.length < 5

Auto label PRs:

Our company is divided into tribes, chapters and squads. We have multiple android chapters and we are sharing our code within chapters. We label our PRs so it is easy to filter them per tribe. How to ensure that a PR has a label?

# Add label to a PR, if ticket belongs to a squad from A or B, otherwise add No-Ticket label.
if github.pr_title.start_with?('SMTV', 'PEAK', 'PLAY')
auto_label.set(github.pr_json["number"], "A", "91f8ff")
message "'A' label added to the PR."
elsif github.pr_title.start_with?('NJOY', 'NGAGE')
auto_label.set(github.pr_json["number"], "B", "dd0471")
message "'B' label added to the PR."
elsif github.pr_title.start_with?('RETE')
auto_label.set(github.pr_json["number"], "Regression", "402448")
message "'Regression' label added to the PR."
else
auto_label.set(github.pr_json["number"], "No Ticket", "0937c1")
message "'No-Ticket' label added to the PR."
warn("❓ This PR has no Jira Ticket.")
end

Warn when common code is touched:

As mentioned above, we share code/modules across tribes. We prefix our modules with “common_” which are shared across tribes. How to get an indication when common code is changed so we can get cross tribe code reviews?

if git.modified_files.include? "common_*"
message "⚠️ This PR is changing common code. Please make sure to add a reviewer from the other tribe."
end

That’s it!

There are few more examples here and also here you can find many plugins that can be used.

--

--

Zahid Rasheed

A human. Being, Technology Freak, Sun hater; snow lover, Enjoys Photography, Live to Travel and Trying to be a better human being everyday.. http://zahid.cc