Improve your code reviews using Danger Swift on Bitrise CI

Andrea Stevanato
Nov 6 · 5 min read
Danger Swift

This article is intended to help you configure Danger Swift with Bitrise. The main goal is to automating the simplest and most repetitive steps of a code review, allowing you and your team to focus on harder problems.

You can integrate Danger into your project using the most common CI services, for a complete list visit the official “Getting started” section.

In my case I used Bitrise, a service I use daily to build and distribute iOS applications, the same procedure may be applied to any other CI service (Teamcity, Jenkins, Travis, etc.)

Note: for simplicity I assume that a basic workflow on Bitrise has already been configured for the project in use.

What is Danger Swift?

Danger Swift is an automation tool that runs after your CI to enforce conventions in code reviews. Danger leaving messages inside your PRs based on rules that you write in Swift.

For example you can write rules that:

  • Enforce CHANGELOGs
  • Enforce links to JIRA in PRs bodies
  • Enforce using labels, reviewers and assignee and any other PR property
  • Look out for common anti-patterns
  • Highlight interesting build artefacts (additions, deletions, files changed)
  • Verify the presence of unit tests or any other specific pattern inside your source files

The core of Danger is the Dangerfile, named by conventions Dangerfile.swift, that contains a collection of rules specific to your project written in Swift.

Danger Installation

Danger can be installed via Swift Package Manager or via Brew. In my case I used Brew:

brew install danger/tap/danger-swift

As mentioned earlier the rules must be specified in a file Dangerfile.swift, these two commands are useful during the development for creating and testing our rules. The first is:

danger-swift edit

that create a standalone Xcode project where you can edit your Dangerfile.swift. The second is:

danger-swift pr https://github.com/your_account/your_project/pull/1

that command allows to test your rules directly from command line without necessarily having to push code into the repository. You should only have an existing PR to link.

Create a personal access token on Github

To allow Danger to work properly on Bitrise, i.e. add comments in your pull requests must be generated a personal access token from your Github account.

Optionally: you could create a bot account (a normal Github user account) used specifically for this purpose.

In the creation form you need to select all the repo scopes like the image below.

Github -> Profile-> Settings -> Developer settings -> Personal access token

After creation keep the access token safe, if you lose it, you’ll have to recreate it again.

Configure Bitrise CI

If you are familiar with Bitrise you will certainly know the concept of workflow, that is the flow of operations that are carried out during a build.

First of all you need to add a new script step at the end of your build process:

Script step
Script step

the script installs Danger Swift and executes it. A possible implementation is given below:

#!/usr/bin/env bash
# fail if any commands fails
set -e
echo "################### DANGER ######################"echo "Install Danger"
brew install danger/tap/danger-swift
echo "Run danger"
danger-swift ci
echo "#################################################"

The next step is to allow Danger access your PRs by setting the Github personal token you created earlier. In the workflow editor, select the tab Secrets and add a new environment variable named DANGER_GITHUB_API_TOKEN and valued with the Github personal token.

Remember to enable the options “Expose for Pull Requests?” like the image below.

Bitrise workflow editor, “Secrets” tab

Create your own rules

Finally you are ready to import Danger into your project. Create Dangerfile.swift on the root of your Xcode project. Below is an example with some simple rules.

Dangerfile.swift

Give it a try!

It’s time to try out what’s been done and make sure it all works. First of all create a new branch and push your danger file. Make an empty PR that does not respect the rules you wrote, for example a short title or an empty description. When the build on Bitrise is finished you should have an additional check regarding Danger, like the image below:

In addition, a message should be added to the PR with output generated by Danger:

Generated PR message from Danger Swift

Next step: Plugins!

Danger is designed to be extended through plugins.

An extension I would like to try and which is now fully integrated in Danger is Swiftlint. More information here.

Another interesting plugin is danger-swift-coverage which helps to display Xcode’s code coverage files in a friendly way.

Conclusion

I consider Danger an excellent tool to give fast feedback to the team and increase productivity by leaving repetitive task to automation. The integration of this tool should be gradual and the rules created in agreement with the members of the team, create positive rules and celebrate the achievements with 🎉 and 👍.

You can get more information reading the official documentation and find other examples of Dangerfile at these links:

Let me know if you found the article interesting. Thanks for reading.


You can connect me on:

Twitter — @andrea_steva

Linkedin— https://www.linkedin.com/in/stevanato-andrea/

Andrea Stevanato

Written by

Software Engineer - iOS Developer @DoveConviene