Keeping check on your Android Libraries with Danger & Bitrise

When you’re working on large projects, sometimes it can be difficult to ensure that all of your libraries are kept up-to-date. Whilst we can periodically jump into our build.gradle file, this is a manual task and let’s face it, us humans can sometimes slip a little when it comes to this. We recently had a notice from a third-party SDK about a performance issue in the version of their SDK we were using – whilst this wasn’t a breaking change, it’s something that would have saved them (and us) time if this library was already up-to-date. In-between tasks I spent a a small amount of time putting together a quick and simple automated solution that will help us to keep on top of our library versions.

Note: If you haven’t already, you may need to follow along with this article to setup Bitrise with Danger.

When considering the implementation of this task, I wanted to put something together quickly, – which ruled out created some form of custom solution. For our setup I knew that we needed to carry out a couple of different operations:

Seems pretty straightforward, right? The biggest task there is scanning for out-of-date libraries – but luckily I found this sweet gradle plugin that analyses all of the dependencies in your gradle project. The only thing with using this was that there was a lot of information in the report that we didn’t need – after all, we don’t want to overload our PRs with a lot of textual content! As per the documentation, you can add this to your project like so:

apply plugin: "com.github.ben-manes.versions"

buildscript {
  repositories {
  jcenter()
}

dependencies {
  classpath "com.github.ben-manes:gradle-versions-plugin:$version"
}

Now if you run ./gradlew dependencyUpdates then you’ll see the content of the task printed out in your console – pretty awesome right! Other than the overload of information for our requirements, this also isn’t entirely automated just yet – we’d still have to remember to run this every so often to ensure our libraries are kept up-to-date.

Now that we have our library information, our next requirement here is writing the content of this report to a text file so that we can make use of it in our CI. When we run this command, we can supply and output directory for the content to be written to:

./gradlew dependencyUpdates -DoutputDir=some_directory

Now after this command has been run, the content of the file will be written to a file at the given directory. And now that we have this step of our process implemented, we can go ahead and add it to a bitrise workflow step:

At this point our dependency information has been collected and written to a file in our bitrise directory, now we just need to tell our dangerfile to handle this content.

fileContent = File.open("/bitrise/report.txt", "rb").read
toRemove = The following dependencies have later milestone versions:
contentToPrint = fileContent.slice(fileContent.index(toRemove)..-1)

warn(contentToPrint)

Let’s take a quick look at what’s happening here:

• We being by fetching our report file from the directory which we wrote it to
• Because at this point we have a lot of content which we don’t really want to print out in our PR, we’re going to go ahead and strip out the content we don’t need. Because the content that states our libraries are out of data begins with the string stated in toRemove, we’re going to look for this string and strip out all of the content before this.
• In this step we take out file content and slice out everything that appears before our toRemove string. This result is stored in contentToPrint and means that we now only have the information about out-of-date libraries.
• Finally, we use the warn() function to tell Danger to log out the data from the contentToPrint field that we previously created.

With all this put together, once our commands have been run and Danger is executed we will see something similar to the following logged onto our pull requests:

From here there are some improvements we could make. Maybe we want to detect when there are no libraries that are out of date – in this case we could either not log anything, or let the author know that all the library versions are up-to-date. We could also format the result to make it a little easier to read and exclude some of the content that is currently shown.

This quick implementation allowed us to add some automated checks so we can ensure that our library versions are always kept up-to-date. Are you doing something similar in your setup? We’d love to hear about it if so! And if note, hopefully this will help you to get something in place for yourself ?