Speed up your PRs by splitting Danger in two

At the iOS team at Lifeworks we’ve been using Danger since its inception. We care about the etiquette of our PRs and the more that can be automated the better.

I love Danger so much that we use it for two different purposes, or at least, for things that have some technical differences.

1. Danger makes sure that the PR itselfs follows standard rules. Our PR etiquette. This are things like including the JIRA ticket number on the title, a link on the description, overview, screenshoots, etc. Anything to make the life of the reviewers easier.

1. After Xcode has finished building and testing Danger reports the results back to the PR.

Note that we use Danger as part of our CI pipeline with Fastlane. I still haven’t looked at Peril but I’m pretty sure that it would improve things.

The issue with the second use case is that it forces Danger to run after the build and tests have finished in order to have access to the Xcode results.

But if there are issues on the PR itself there is no need to wait for Xcode and get the results late, that’s a waste of time.

Thankfully Danger and Fastlane allow you to run Danger multiple times!

You just need to tweak your Fastfile to execute two instances of Danger with a different IDs:

danger(
   danger_id: "PR",
   fail_on_errors: true
)

scan() // this takes a long time

danger(
	danger_id: "Build",
	dangerfile: "DangerfileXcode"
)

• danger_id: This is an ID that Danger puts in its comment to know what to update in subsequent runs. It needs to be different otherwise the second execution of Danger would overwrite the comment of the first one.
• dangerfile: This is the file name that Danger executes. By default is Dangerfile but you can specify a different one, and thus execute multiple things on each run.
• fail_on_errors: This flag is really useful If you have some things on the first execution that are mandatory and that if they are not correct it doesn’t make any sense to continue the execution. The side effect is that the CI won’t be busy for no reason, which will make other PRs go faster or allow you to pay less on your CI bill.

One of the inconveniences, and the reason I mentioned Peril before, is because the Danger checks on the PR won’t go away unless you make a new commit. This is because the CI pipeline only runs on commits, not on PR changes (which makes sense for Xcode results but not for PR etiquette).

I’m really happy with this setup as quick feedback in PRs is really important for our productivity. I take any opportunity I have to improve and automate our workflow and Danger is a big part of it.