"Danger runs during your CI process, and gives teams the chance to automate common code review chores. This provides another logical step in your build, through this Danger can help lint your rote tasks in daily code review. You can use Danger to codify your teams norms. Leaving humans to think about harder problems. She does this by leaving messages inside your PRs based on rules that you create with the Ruby scripting language. Over time, as rules are adhered to, the message is amended to reflect the current state of the code review."
Setting it all up!
Bundler is a dependency manager for Ruby which uses a Gemfile to define all of the Ruby projects you want to use.
Let's open up your Terminal app and head to your project's path. If you don't have Bundler installed to your system, type in the following command. If you hit any permission issues try with sudo.
If you don't have a Gemfile in your app's repository, type in bundler init in your project folder. This creates your Gemfile.
This will generate the following Gemfile for you.
You can also open the Gemfile in your favorite editor and remove #gem 'rails' to keep it nice and tidy.
Now you can install and validate the installed version:
It's a common practice to install the gem this way, not globally. This way you can make sure that anyone who joins the team will be using the same version as you are. Don't forget to commit the Gemfile and Gemfile.lock file to your repository!
Adding Danger to your project
The easiest way to add Danger to your project is to run
This will guide you through the setup and it will automatically create a sample Danger file for you, but on GitHub you have to create a new Bot user for your project and also a Personal Access Token for said Bot. (Save this token, we will add it later to Bitrise.) If it's a closed project you will need to add the Bot as a collaborator.
Commit your Dangerfile and push all the changes to the repository.
Setting it up on Bitrise
Add your app to Bitrise, go to your Workflow Editor and add the newly generated token as an environment variable. For GitHub projects use DANGER_GITHUB_API_TOKEN
Then add a script step after your tests with the following content:
You can also change your bitrise.yml file to make sure Danger is only running for pull requests.
Now that we are all set up, let's see some cool examples! 👾
Mark Work In Progress pull requests 🔨
Let's start with the initially created Dangerfile in your repository.
If you open up the file you will see the following lines in it. This will make sure that your Work In Progress Pull Requests are visible for your team as well.
To test this, create a new branch with a simple Readme file change and when you are done with everything push it to the repository and create a pull request, with [WIP] in the title.
If you've set up everything correctly, you should see this appearing in your PR:
Check for release notes changes 📋
Let's change your Dangerfile a bit and add a logic that checks for your release notes file.
During the check we can validate every non-trivial Pull Request whether the release_notes.txt file was changed or not. If not, we can simply return an error for the Pull Request.
Let's commit this to a new branch and create a Pull Request. After running it on Bitrise you will see the error as we did not change the required file at all.
List those build artifacts 📱
If you would like to include your IPA or APK file in the Pull Request for your testers, you can simply do so by moving your script step after the Bitrise deploy step in your app's Workflow Editor on Bitrise and then changing your Dangerfile:
After running a new build you and your QA guys should see this:
We just wanted to show you a couple of examples on how you can integrate Danger into your Bitrise workflow. But there is more to it, as usual. 😱
We are very keen on learning about your use-cases, so if you are working on this, definitely let us know here or on our Slack channel! 😍
Happy coding! 🚀