Gradle Enterprise 2017.3

The recent Gradle 3.5 release introduced a new build caching feature that makes builds faster by reusing task outputs where possible instead of building them again (see the introductory blog postdescribing how this works and what kind of speed gains are possible). Gradle Enterprise 2017.3 adds a build cache that can be used to enable caching across machines.

The build cache is part of every Gradle Enterprise installation. Using it is as easy as configuring your Gradle build to use a HTTP build cache with the address https://your-gradle-enterprise-server/cache/ (see the Gradle Enterprise Admin Manual for more details).

By going to https://your-gradle-enterprise-server/cache-admin in your browser, you can view stats on the cache, change cache size and credentials, and view recent cache activity.

Using a build cache is a very effective way to realize faster builds, and the Gradle Enterprise build cache is the fastest and simplest way to deploy and run a shared build cache. Additionally, build scans provide essential insights and feedback on cacheability configuration within your builds.

To learn more about build caching, please see this page.

Gradle Enterprise 2017.1 introduced dependency comparison, allowing you to quickly and easily discover differences in resolved dependencies between two build scans. In this release, you can now also compare the environment/infrastructure and the Gradle configuration switches of two builds.

The infrastructure/environment section contains information about the JDK used to execute the build, the machine’s host name, number of cores, memory allocation etc. Differences in these aspects may explain different performance profiles, or even differences in build behavior.

The switches section outlines whether or not different Gradle configuration switches were used, such as, --parallel, --continue, --refresh-dependencies and others. Differences in these aspects may also explain different performance profiles and differences in build behavior.

Understanding the differences between two builds quickly can make debugging and root cause analysis much more efficient and effective. Expect more comparison functions in upcoming Gradle Enterprise versions.

The performance section of a build scan offers a breakdown of the build’s tasks, including a breakdown by the execution outcome (e.g. SKIPPED, UP-TO-DATE). This now includes the combined time taken by all tasks in each category, which can help to qualify decisions about whether to invest in further build optimization.

Additionally, the overall build time breakdown provided in the “Build” tab has been refined to include additional categories and useful explanations of exactly what each item represents as a tooltip.

Gradle Enterprise processes and analyzes build data in the background after each build scan has been uploaded. If something goes wrong during this process, or with any other aspect of Gradle Enterprise’s operation, a notification will be issued in the app directing the installation administrator to contact Gradle Inc. support to have the problem resolved.