Gradle Enterprise 2017.1

Changes to dependencies are a common source of issues. The new build comparison function highlights the differences in the resolved dependency graphs of two builds, making it significantly easier and faster to find out what changed.

Builds to be compared are selected and pinned from build search results. They can easily be shared via the scan list URL.

Pinning a build in the scan list is also possible from the build scan page.

The comparison visualization identifies discrepancies between the resolved configurations of the two builds, and between the dependencies of matching configurations between the two builds.

The new timeline provides a far more intuitive and powerful representation of when tasks were executed during the build and how long they took.

Visual prominence is given to longer running tasks, making it easy to identify where to invest optimization efforts.

The timeline really shines when using parallel execution. Bottlenecks and utilization become apparent, pointing out optimization opportunities.

Tasks can also be filtered by name, type and more, making it easy to inspect and highlight particular tasks within the timeline.

Try it out with this timeline from the Gradle project.

Network requests made during dependency resolution can significantly impact build performance. The new “Network Activity” tab in the “Performance” section lists and summarizes the downloads during the build.

Differences in files downloaded and the speed in which they were downloaded can contribute to the difference in build time between two builds.

This feature requires Gradle 3.5 or later and build scan plugin 1.6 or later.

Try it out with this example scan.

The new Export API provides a mechanism for consuming the raw build data that powers build scans. It is a HTTP interface based on Server Sent Events (SSE) that supports real time data integration. Libraries for consuming SSE streams are available for most programming languages.

The video below demonstrates a real time build duration dashboard built on the Export API. The code for this is available as part of the gradle-enterprise-export-api-samples on GitHub.

The manual for the Export API provides the technical details and instructions for using the API.

Gradle 3.3 introduced the build cache feature, which makes builds faster by reusing task outputs from other builds. For a task to be cacheable (i.e. can contribute cached outputs, or use them), certain conditions must be met.

The “Settings and Suggestions” tab of the “Performance” section now indicates if there were tasks that were not cacheable.

The new timeline section provides details on the cacheability of the individual tasks.

This feature requires Gradle 3.4 or later and build scan plugin 1.6 or later.

Try it out with this example scan.

The “Task Execution” tab of the “Performance” section summarizes the tasks of the build in terms of work avoidance (or their potential for work avoidance). This summary has been significantly improved in this release to make it much easier to identify problems and optimization opportunities.

Gradle can avoid executing a task by way of its incremental build feature (i.e. it can reuse the work from the previous build execution), or via the new build cache feature where outputs are fetched from a shared cache.

The improved summary makes it clearer which tasks were avoided, and out of those that weren’t, which could have potentially been. This information can help identify optimization potential within a build, or misconfiguration. Clicking on an entry in the summary shows the corresponding tasks in the timeline view.

Try it out with this example scan.

Each tests view (global, by project, failed tests) is now searchable. As usual, the URL is updated to help you share your results with your team.

Try it out with this example scan.

The build scan plugin allows annotating a build with one or more tags, for descriptive or categorization purposes.

In previous versions of Gradle Enterprise, it was possible to find scans based on the presence of a tag. It is now possible to also find scans based on the absence of a tag by using a not: prefix when searching.

Please see this “Custom Data in Build Scans” post for more about how and when to use tags.

Searching for build scans is now dramatically faster as search results are now returned much sooner, particularly when searching over many build scans.