Tuesday, August 21, 2012

The perils of gradle wrapper and CI

If you are building yours software with Gradle, using gradle-wrapper is a great thing to ensure that your build is able to run out of the box after checking out just by running "gradlew" in your project directory.

Just today I got a nice message from Hans Dockter (gradleware Germany), telling me that there have been a lot of downloads of gradle-1.0 (about 2100) in the course of one or two months, which caused some notable trafic on gradle.org.

 2100 downloads check in at about 64 GB of data.

So, what was the cause? As we don't have an infinite number of monkeys using gradle here, the primary suspect is jenkins.
A good number of jobs (about 20) use Gradle for building, and each job is configured to use Gradle wrapper, because it is convenient and ensures the build runs exactly with the right Gradle version.

So it seems like every job was happily downloading Gradle over and over again, which puts some load on gradle.org (bad)  and slows down the build (even worse).

The solution is simple: Just installGradle centrally on your Jenkins and configure the Jenkins jobs to use the centrally provided Gradle instance. I am dong this for my jobs right now and I expect them to behave better afterwards.

I am sure that gradle.org and the speed of your build jobs will thank you for it.