We Are Mobile First
If you’re a software developer, it’s highly likely that you have witnessed many cycles of code reviews and pull requests. Accuracy is key when it comes to the reviewing stage of the development process but how can we make it less time-consuming?!
In today’s post, we will be exploring the Danger tool before explaining how to integrate it into our continuous integration system of choice, Travis CI. When we tried to integrate the Danger tool in Travis CI for Github, to help us assess our Android projects, we found that the documentation wasn’t particularly accurate. In this post, we’ll provide you with a frustration-free way of setting up Danger within an hour!
Danger is a tool that helps automate common code review chores, allowing you to create and share automated messages that remind the user of common mistakes so that they don’t run into them time and time again.
It also allows you to set a handful of specified guidelines that every pull request has to follow before getting approved, saving developers a great deal of time when it comes to assessing the accuracy of their code review.
Danger is a powerful tool so you can even create your own custom rules, using the Ruby scripting language, that can be left in a Dangerfile inside your project. You can set different messaging options, from warnings to direct rejections of the pull request, depending on the severity of the mistake made.
Danger can go over the pull request metadata, both the code and the description, to ensure that it makes a thorough assessment. For instance, say we needed to follow a set of code style guidelines in order to be efficient. The Danger tool will add messages where the rules are broken in each part of the code review, allowing you to focus on what’s important and needs the bulk of your attention first.
Now that you know what Danger is and how it can be useful, it’s time to install it!
We found that the easiest way to do this was to install it via Bundler and a Gemfile. Bundler is a dependency manager for Ruby which uses the Gemfile to define all of the Ruby projects you want to use during the process.
If you don’t have Bundler installed on your system, you’ll be glad to know it’s pretty straight forward!
This will install Bundler onto your system. Once it’s installed, you’re ready to create the Gemfile in the root of your project:
<p> CODE: "https://gist.github.com/albertmiro/35a9ac7d7230e5f63dc5857fc972429d.js"</p>
You can then modify the Gemfile that Bundler has created by adding the Danger tool to it:
<p> CODE: "https://gist.github.com/albertmiro/035194c96bc1645ed9600406687a077c.js"</p>
Once you’ve completed those steps, it’s time to run the following command:
<p> CODE: "https://gist.github.com/albertmiro/fd40455fd64de7ac3ec2cc4a335c0372.js"</p>
This will install the projects that you have in your Gemfile which, in this case, is the Danger tool. Let’s now initialize Danger:
<p> CODE: "https://gist.github.com/albertmiro/a518644e337c1d94173260672282e9cd.js"</p>
If you need further assistance with any of the aforementioned steps, or you want to research other ways of getting started, you can head to the Danger website.
Now that it’s initialized, we can start looking at ways in which we can set it up to work in conjunction with our continuous integration system of choice. Our Android team uses Travis CI so, in this post, we’ll be focusing on how you can use the two together.
Firstly, you’ll need to open your Android Studio project – modifying the ‘.travis.yml’ file to let him know that he has to run Danger.
Once you have located this file, add the following lines of code:
<p> CODE: "https://gist.github.com/albertmiro/d41cb135eb55159b27b898e17743c48b.js"</p>
By clicking ‘bundle install’, Travis will start looking through the Gemfile to execute the gems that are there. He’ll then install the necessary dependencies for your project.
Once the dependencies are installed, we can run ‘bundle exec danger’ which will then execute the Danger tool. You will be able to see another line, this refers to running Lint checks, but we’ll come back to that later….
You should now have the basic configuration setup in your Android project.
The next step is an important one. You’ll need to create a new file, called ‘Dangerfile’. This is where you’re going to define the rules that you want Danger to check. Let’s kick things off by creating a really simple ‘Hello World’ rule.
All you need to do is write inside the Dangerfile like so…
<p> CODE: "https://gist.github.com/albertmiro/f4522e4f8e2c8d4bd55ce147af8c3113.js"</p>
Once you’ve accomplished that, you’ll have finished the Android Studio part of the process! What a time to be alive! It’s not over just yet, however, as it’s now time to turn our attention to GitHub and Travis.
First of all, you’ll need to create a new GitHub account that you’re going to use as a bot. This is the bot that Danger will use to write the messages in the pull request. See, there’s a method to this madness!
Once you’ve created your new account, you should go to https://github.com/settings/tokens/new to get the token. With your token in hand, we can now head over to Travis.
Open https://travis-ci.org/[user]/[repo]/settings and modify your user and repository where you want to add Danger. Add a new environment variable called DANGER_GITHUB_API_TOKEN. It’ll look a little something like this…
With that done and dusted, you’re ready to go!
Danger allows us to check details when someone opens a new pull request on our Github repository e.g the description, title, if an important file was modified, etc. All of these rules, however, have to be configured on our Dangerfile.
We typically use five types of messages:
Let’s look at an example. Let’s say we want to send a warning message to the developer if the pull request has more than 500 modified lines of code. We’ll firstly need to access git.lines_of_code and check the number of lines modified.
We’ll then need to make a rule that warns the user, ‘warn()’, but doesn’t block the CI process. If we want to block the CI, however, we will make a ‘fail()’ instead. Whilst we’re there we’ll also want to check if the author has written a good description of the pull request e.g if it’s more than 5 characters long.
<p> CODE: "https://gist.github.com/DavidFD005/282cf6014f822d96176e502ea907e67c.js"</p>
If we now open a new pull request, without a description and with more than 500 lines of modified code, and go to run the CI, we should get two messages from Danger’s bot.
You can head to Albert’s Github to see more examples of warnings that we are currently using on our CI:
<p> CODE: "https://gist.github.com/albertmiro/5c729421836abbcbe37a1123002bf823.js"</p>
Code reviews are a must but they aren’t exactly the most enjoyable things are they?!
Thanks to tools like Danger and Android Lint, we can now automate aspects of our code reviews so that we can focus on more constructive things. For instance, they allow you to add inline comments on the pull request that target things like typos and formatting. How handy?!
Want to know how you can do the very same?
Firstly, you’ll need to run Klint. This will generate the required errors that are highlighted when our code is run against the rules that Klint defines.
Klint’s default rules are based on the standard Kotlin code styling, meaning that when we get these errors Klint will generate a report that collects them. This report can be found here:
We then need to run Android Lint as Klint only handles the styling errors. Android Lint highlights, you guessed it, Android errors such as deprecation warnings, library updates, etc. This report can be found here:
Finally, we’ll need to run Danger as it’ll be responsible for writing the comments on GitHub.
Before we can get started, however, we’ll need to set up our Android project to support Klint and we’ll then need to modify our Dangerfile to support both Android Lint and Klint.
Let’s setup Klint. We’re going to use a Klint plugin in order to make things slightly easier! First things first, we have to add this plugin on project build.gradle…
<p> CODE: "https://gist.github.com/DavidFD005/18e84a69ee1038c9e41af2eb6f41d077.js"</p>
…and then apply the plugin to our build.gradle of our module (or app in our case) before adding some settings:
<p> CODE: "https://gist.github.com/DavidFD005/0b46add4332620015a95e440aea59e4c.js"</p>
Once synced, we need to run the Android Studio console to check we did it accurately:
If you go to the build/reports/ktlint directory, you will see the generated reports.
We now need to run Android Lint. We’ll do both calls inside a ‘gradle’ method. This method will be called from the Android Lint Danger plugin:
<p> CODE: "https://gist.github.com/DavidFD005/b1d0bca853dc37d96ead547641d872a2.js"</p>
You should now be able to run ./gradlew runChecksForDanger from the Android Studio console.
The last thing we need to configure is Danger, as explained at the beginning of this post, before adding the aforementioned plugins to Danger.
As previously mentioned, we have to add the plugins danger-checkstyle-format and danger-android_lint. We’ll do it using Gem:
The first plugin, danger-checkstyle_format, will provide us with a checkstyle report for Danger from Klint. The second plugin, danger-android_lint, will provide us with the report from Android Lint.
Once you’ve installed these plugins, you’ll need to configure them within your Dangerfile:
<p> CODE: "https://gist.github.com/DavidFD005/20e03a349dd8c8a2caad528a6a181e6e.js"</p>
As you can see, we added the gradle task to call it from Danger and generate the reports that Danger will then use to write the comments on the pull request. We have added this important param github.dismiss_out_of_range_messages to write the comments on the files that are on the scope of the pull request (modified files). We’ve added the inline comments with the param android_lint.lint(inline_mode: true).
Lastly, we have to add the ‘Run’ command for Danger on our CI so it’ll take care of the rest for us:
The result on Github will look something like this…
And there you have it! That was a lot of information, huh?!
You should now, however, be able to use the Danger tool to help simplify your code reviews ensuring accuracy at every step of the process!
---
Do you use the Danger tool? We’d love to know about your experiences using it. Tweet us at @WeAreMobile1st and we’ll be sure to retweet your responses.
Follow us on Twitter, LinkedIn or Medium to be notified of our future posts. We share weekly posts on everything from how we helped to create Ed Sheeran’s infamous loop pedal to how we helped to change the face of the commercial car insurance industry in NYC.
(Hero image credit: Roman Bozkho via Unsplash)