Improve your code reviews using Danger Swift on Bitrise CI
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.
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:
the script installs Danger Swift and executes it. A possible implementation is given below:
#!/usr/bin/env bash
# fail if any commands fails
set -eecho "################### DANGER ######################"echo "Install Danger"
brew install danger/tap/danger-swiftecho "Run danger"
danger-swift ciecho "#################################################"
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.
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.
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:
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