At buddybuild, our focus is to help automate the tedious and time-consuming aspects of your development workflow to give you the time needed to create great applications. Danger, a popular open source tool, has a similar philosophy - it allows you to automatically apply a common set of rules to code reviews.

Overview

Danger is a tool that runs as part of your continuous integration process. Using a domain-specific language, it lets you define any arbitrary set of rules that suit your team’s pull request code review practices. For example: checking that the pull request might have modified some sensitive files and that the whole pull request needs to be carefully reviewed.

Editorial Note: This post covers the original Danger tool, written in Ruby. There’s also a javascript version that we'll cover in a future post.

Getting started with Danger

Setting up Danger in your repository is a straightforward and well-documented process. This helpful guide describes, step-by-step, how to get started with Danger, how to create a token on Github, etc.

The first thing you need to do is add the danger gem to your project. The easiest way to do this is to use bundler and a Gemfile . If you're not familiar with bundler , it's a dependency manager for Ruby libraries and tools. A gem is a Ruby library or application. A Gemfile declares which Ruby gems that bundler should install.

Here’s how to create a Gemfile , add Danger as a dependency, and install Danger:

gem install bundler bundle init echo "gem 'danger', '~> 5.5', '>= 5.5.3'" >> Gemfile bundle install bundle exec danger --version # "5.5.3"

Editorial Note: Alternatively, you could install Danger globally. However, it's considered good practice to setup your project as self-contained. Using a Gemfile is a great way to maintain a reproducible environment, as it helps you to avoid issues where it works on your local machine but not on buddybuild.

Now that Danger is installed, you can incorporate it into your project. We recommend creating a setup-danger branch — later on, we’ll open a pull request from this branch:

git checkout -b setup-danger

Next, we can configure Danger. Run the Danger command-line tool in the root of your repository:

danger init

Danger's command-line tool guides you through the required steps. The configuration process asks you to create an access token and make it available to Danger. To achieve this, go to App Settings > Environment on buddybuild’s dashboard and follow our documentation.

Running Danger as part of your build

The generated Dangerfile comes with a few examples of what you can do and how to add messages to the code review:

# Make it more obvious that a PR is a work in progress and shouldn't be merged yet warn("PR is classed as Work in Progress") if github.pr_title.include? "[WIP]"

Running danger locally is as trivial as adding a step to your build process. Buddybuild already supports the postclone , prebuild , and postbuild scripts, so it's up to you to choose which step you’d like to use to run Danger at. Our recommendation would be to run it after the build happens.

Create a buddybuild_postbuild.sh at the root of your repository with the following content:

#!/bin/bash chruby 2.3.1 bundle install bundle exec danger --fail-on-errors=true

Editorial Note: use chruby to select a recent version of ruby. Version 2.3.1 is already available on your build machine.

Once this is done, don’t forget to commit your new Dangerfile and push the setup-branch you created earlier.

git add Dangerfile git commit -m « Setup danger with basic rules » git push -u origin setup-danger

Then, open your repository on Github and open a pull request with that branch.

Editorial Note: Don't forget to add [WIP] to the pull request’s title so that Danger warns reviewers that the pull request is still a work in progress.

Buddybuild notices your PR and starts building your application. If everything works as expected, you should see a comment from your Github user on your pull request.

Once we’ve set up Danger for our projects, we can start adding new rules throughout our development to ensure that we’re maintaining the quality of our codebase.

Examples of how mobile development teams use Danger CI

The above default example is a great way to get started with Danger. Now, let's take it a step further and see how development teams use Danger in their workflows.

We asked our friends at FreshBooks about their use of Danger and the role it played in their workflow. They use it for two important aspects of their code review: making sure that the code style is respected with Swiftlint, and maintaining a certain code-coverage percentage.

Using Danger to make sure the code style is respected

Swiftlint is a tool, created by the people at Realm, that uses Clang and SourceKit to parse your source files and check them against a set of customizable rules. Let’s see how we can add it to Danger, starting by adding the danger-swiftlint dependency to your Gemfile. Don’t forget to run bundle install once it’s done so that the dependencies are installed.

gem 'danger-swiftlint', '~> 0.5.1'

Then, add Swiftlint to your Dangerfile:

swiftlint.lint_files

Danger checks all the modified files and added files in your pull request, listing all of the violations in a comment:

Using Danger to maintain code coverage percentage

Let's see how to use Danger to maintain a certain level of code quality based on code coverage. Below we’ll walk through how the FreshBooks engineering team pairs buddybuild and Danger to accomplish this.

Buddybuild already shows the code coverage percentage as part of your build's information.

Including the code coverage in the pull request can help reviewers decide whether the pull request’s changes are tested sufficiently. For this, Danger can help. We’ll be using the danger-xcov library.

Start by adding this gem to your Gemfile , just like we did for Danger itself:

gem 'danger-xcov', '~> 0.3.3'

Don’t forget to run bundle install once it’s done so that the dependencies are installed.

danger-xcov needs a bit of information to work: the Xcode scheme, the path to the project, and the path to the derived data. All of these are available as environment variables. You’ll also need to provide the minimum code coverage percentage you want to maintain. In this example, we'll use 30%.

To achieve this, add the following instructions to the Dangerfile :

xcov.report( scheme: ENV['BUDDYBUILD_SCHEME'], project: "#{ENV['BUDDYBUILD_WORKSPACE']}/Project.xcodeproj", minimum_coverage_percentage: 30, derived_data_path: ENV['BUDDYBUILD_TEST_DIR'], )

If you commit and push your changes to your pull request, you'll see a code coverage report in your pull request. If the code coverage of the modified files in the pull request is less than 30%, then Danger fails the build.

Adding Release Notes using Danger and buddybuild

Every time you distribute a build to your application’s stakeholders, remember that to provide useful feedback they need to know what changed. It can be a bug you fixed, a feature you added, or a piece of UI that you tweaked.

You can provide added context to your stakeholders in the buddybuild_release_notes.txt file. If this file exists at the root of your repository, its content is displayed as the release notes to your users.

Developers often forget to update release notes, and reviewers often forget to check that the release notes have been updated. This is exactly where Danger starts to shine.

The following example checks to see if Swift code has been modified. If so, it also checks whether buddybuild_release_notes.txt has also been modified. If not, Danger warns you.

modified_code = git.modified_files.include? "2048/*.swift" updated_release_notes = git.modified_files.include? "buddybuild_release_notes.txt" fail "You forgot to update the release_notes_file ([docs](http://docs.buddybuild.com/docs/focus-message))" if modified_code && !updated_release_notes

Conclusion

These examples demonstrate how Danger can improve the quality of your project by automating portions of your pull request code review workflow. We hope these examples inspire you and your team to incorporate Danger into your projects.

If you have any questions, thoughts, or suggestions on how to improve buddybuild’s integration with Danger, we’d love to hear them. Feel free to reach us @buddybuild on Twitter, or by emailing team@buddybuild.com.

Are you already using buddybuild and Danger in your development workflow? We’d love to include your workflow as an example in this post. To be included, please contact romain@buddybuild.com directly.

Stay tuned for a blog post about how to integrate and use the the javascript version of Danger with buddybuild!