At the Gradle Summit conference earlier this year, the Gradle team introduced Gradle Cloud Services alongside version 3.0 of the Gradle build tool. These services “improve build automation effectiveness and productivity by adding new capabilities to the Gradle build tool and offering new insights into how you and your team build software.” The first of these cloud services provides support for build scans .
As defined in the Gradle build scan user manual :
Build scans are an important tool for developing and maintaining Gradle builds. They provide insights into exactly what your builds are doing, helping you identify problems with the build environment, dependencies, performance, and more. They can also help you understand and improve the build more generally, and make collaborating with others easier.
The Build Scan Plugin captures data while a Gradle build runs and transfers that data to the Build Scan Service. This returns a link to that build data as useful information that can be shared with other developers. That information is classified into two categories:
Source code and project artifacts, such as JAR files, are not recorded.
Adding a build scan to an existing Gradle project requires adding the following configuration to the build.gradle file:
To initiate a build scan, add the command-line switch, -Dscan , to the build command for the project:
After a simple activation process, build information for the project can be viewed online and shared with other developers via permanent links. This allows developers to collaborate and fix issues faster and evaluate build performance.
Given a project that fails a unit test or has a source code error, the resulting build scan will look like the example shown below:
Conversely, a project that passes all its unit tests and is otherwise successfully built, the resulting build scan will look like the example shown below:
In both examples, information can be interactively viewed. Build times are reported in various sections of the build scan so that performance can also be monitored.
A complete sample project can be found on the GitHub repository .
A number of prominent open-source projects, such as Hibernate , JUnit 5 and Ratpack , are using Gradle build scans when developing their respective projects .
Chris Beams , director of marketing at Gradle, spoke to InfoQ about Gradle, Gradle Cloud Services, and build scans.
InfoQ: What is your current role at Gradle?
Beams: I direct our marketing efforts here at Gradle Inc. Previously, I was a principal engineer with the Gradle build tool team.
InfoQ: It would appear that Gradle is separating itself from the other build tools, such as Maven , Ant and Pants , with features such as the Gradle daemon, the new Gradle Cloud Services, and build scans. Do you expect the others to follow suit?
Beams: Probably not. The Gradle daemon in particular is the product of years of work and refinement. It’s not the sort of “me too” feature that other build tools can easily implement—at least not in a production-ready fashion. Bazel is a notable exception here, as they are based on a client/server model similar to the Gradle daemon.
And Gradle Cloud Services—including build scans—go well beyond the traditional boundaries of build tool features. They’re part of what we see as a larger platform for build automation. This kind of platform-building is ambitious stuff, and that means it’s relatively unlikely that other build tools will try to follow suit—at least not without the backing of a company dedicated to build automation and willing to make significant bets on it.
