Gradle Enterprise 2018.2

Build scans have long provided detailed performance information for individual builds. Now, you can easily comprehend key aspects of build performance across many builds.

The new performance dashboard is an interactive and multidimensional graph that analyzes builds matching search criteria.

The default view charts build time, serial task execution time (the sum of the durations of each task),avoidance savings (how much time was saved by incremental build and build cache), and build cache overhead (e.g. cache entry download time). Clicking on a metric focuses it, breaking it down into its constituent parts. For example, focusing on build time breaks it down between initialization & configuration and task execution.

The mean value for each metric is given, along with key percentile values.

Each bar in the graph represents a build. Clicking on an entry presents the relevant details of that build, and allows navigating through to the corresponding build scan for more detail or nominating the build to be used in a build comparison.

There are many potentially interesting data sets to analyze. For example, all builds by a certain user of a certain project over the last week (how many builds did they run? how long were their builds? was their remote build cache connection fast?). Or, all builds of a certain CI plan (has build time increased or decreased? how often are we getting good build cache hits? how much time is it saving? is build time dominated by tasks that are not cacheable that we should make cacheable?).

The power of the performance dashboard is amplified when your build scans are enriched with tags and custom values, as these can be used as search criteria. For example, by tagging builds of a certain CI plan with a well known tag, you can easily analyze the performance of these builds in isolation.

Access the performance dashboard by using the view selector at the top right of the scan list page.

Preemptive replication enables better build cache performance, at the expense of more network transfer between nodes.

When preemptive replication is enabled, nodes will copy cache entries from their replication source as soon as they are added. This avoids having to wait for the copy when the cache entry is requested for the first time by a build, as is the case when using the default on-demand replication strategy.

Preemptive replication is not enabled by default. It must be enabled for each node that is replicating from another, via the node’s details page in the build cache admin section.

The new Health page in the build cache admin section of Gradle Enterprise provides an overview of the operational status of your build cache network.

This makes it easier to rectify problems by seeing the status of each node in one place, and to verify that there are no problems.

Proactive alerting is supported by having your organization’s system monitoring tool poll the corresponding /cache-admin/health/monitor endpoint. It provides the status of the nodes in plain text, and responds with a 503 HTTP status code if there are any errors, which will be interpreted as an error state by your monitoring tool.

Captured build scans are stored on the Gradle Enterprise server’s disk. In order to limit the disk space used by Gradle Enterprise, you can now elect to have build scans older than a specified number of days automatically deleted.

This new setting is available under the Storage section of the admin console.

Please see the managing disk usage section of the admin manual for more information on this topic.

The backup process has been rebuilt to be faster and simpler to operate. Previous backup archives remain compatible.

Please note, the previous backup configuration is not automatically migrated. See the upgrade notesfor more information.

When a build fails due to a task failing, a convenient link is now presented next to the failure description that reveals the console log from just that task.

Many tasks provide failure diagnostics in their console log. This link makes it much faster to access this information in a build scan.

The existing Console log section now provides a task path and task type filter for isolating specific task log.

Additionally, when viewing a particular task within the Timeline section, there is now a link for accessing the console log of that task.

Previously, visiting / of a Gradle Enterprise server redirected to the /scans page. Now, a new landing page is shown.

Clicking the Build scans button will take you through to /scans.