Adam Warski

24 Feb 2016

Add a “dependencies” badge & tree to your project using UpdateImpact

softwaremill

Most Java/Scala/Groovy project depend on a number of libraries, these libraries depend on other libraries, and so on for many levels deep. When creating the final project bundle we end up with a large number of external dependencies, which are often very hard to manage.

That’s why UpdateImpact was created: it makes it easy to search the dependency tree, find out why a specific version of a library was evicted, plus detects some common classpath problems, such as multiple logging libraries.

But wouldn’t it be great to be able to browse the dependencies of a library before adding it to your project? Just to verify what will be the impact on your project and what kind of transitive dependencies it has. That way we could avoid many nasty surprises, coming from either incompatible transitive library versions or a dependency we rely on being evicted by a newer version.

This is now possible using the UpdateImpact badge, which you can embed e.g. in your project’s README, just as for example Bootzooka does:

badge

This relies on the CI server submitting the dependency tree information after a successfull master branch build. To submit information to UpdateImpact, you need two things:

  1. add the Maven, SBT or Gradle plugin to your build
  2. define the UpdateImpact api key (available after you register in the service) either in the project’s settings or in the UPDATEIMPACT_API_KEY environmental variable

After you submit your first build and open the dependency tree for browsing, you’ll see the badge in the top-right corner. Click it to obtain the URL of the (dynamic) image showing the number of dependencies of your project & warnings (if any), plus the link which points to the tree of the latest build.

badge

If you want to put the badge in a public place, you should probably also make the project publicly accessible by clicking the “Private / Shareable via link” switch (the private/public setting applies top-level project name).

However, even when you have a public project, it’s necessary to have the UpdateImpact api key hidden. You cannot expose it in the build, it needs to be provided by the CI server and not accessible publicly.

Adding private build configuration on Travis

On Travis, you can do that by going to your project’s settings (available under More Options -> Settings), and adding an environmental variable with “Display value in build log” turned off. And that’s it!

You’ll also probably need to modify the build target that Travis invokes. For SBT, you need to add the following to .travis.yml:

script:
- sbt ++$TRAVIS_SCALA_VERSION test
- '[ "${TRAVIS_PULL_REQUEST}" = "false" ] && sbt updateImpactSubmit || true'

We have two steps here: test is always run, while submitting to UpdateImpact is done only if the build isn’t a PR. That’s because private env variables aren’t visible for PRs (so that they cannot leak due to a malicious change), and you probably don’t want the “latest” UpdateImpact dependency tree to show the results of a PR, only of merged changes.

comments powered by Disqus

Any questions?

Can’t find the answer you’re looking for?