Gradle Enterprise 2019.4

Gradle Enterprise 2019.4 introduces the tests dashboard for identifying and analyzing the most frequently failing tests and test execution time, access control for build scan publication, more fine-grained work avoidance metrics for individual builds, expanded Maven build comparison, and more.

Read on for more details.

Use version 1.3.6 of the Gradle Enterprise Maven extension, and version 3.1.1 of the Gradle Enterprise Gradle plugin for optimal usage of Gradle Enterprise.


Analyze test failure and performance over many builds

This release of Gradle Enterprise includes tools for analyzing test failures and test execution time for Gradle and Maven builds.

The Tests Dashboard is available in 2019.4 as a partial preview of a larger set of testing-oriented functionality that will be available as an add-on package in upcoming Gradle Enterprise versions. Depending on your usage license, this new functionality may not be available to your installation when it is no longer in feature preview. If you have questions regarding this matter, please contact Gradle Enterprise support.

The top tests report shows the tests that fail most frequently for your selected set of builds, along with a daily trend chart.

Selecting a test class shows outcomes and execution times by day, and lists the test methods that fail most frequently.

The single test view also shows stability and performance trends, and lists recent builds where the test was executed.

You can also search for tests you’re interested in by their name. For example, you can search for “” or “*BrowserTest” or “*”.

Learn more in this blog post.

Restrict publishing of build scans to authorized users

Previously, Gradle Enterprise did not provide any means of restricting who can publish build scans. Any user that could make a network connection to the server was able to publish. Now, access control can be enabled for publication and restricted to certain users via role membership.

Build scan publishing access control requires that all builds attempting to publish are configured with an access key. Any user that can log in to Gradle Enterprise is able to create one or more access keys by visiting the “My settings” page after logging in.

For developer environments, the most convenient way to configure an access key for an environment is to use the access key provisioning task for Gradle, and equivalent goal for Maven. For CI environments, it is typically more convenient to set the access key via environment variable. Please see the Gradle Enterprise Gradle Plugin User Manual or the Gradle Enterprise Maven Extension User Manual for more information on configuring access keys for your build environment.

Build scan publishing access control is disabled by default. After enabling, users must also be granted permission to publish.

When access control is enabled, attempting to publish a build scan without configuring an access key or without permission does not cause build failure. A message will be included in the build log indicating why the build scan could not be published, without affecting the build outcome.

Please see the Gradle Enterprise Admin Manual for more information on access control configuration.

In order to use build scan publishing access control, it is recommended to first upgrade all builds to use version 3.1 of the Gradle Enterprise Gradle plugin or 1.3 of the Gradle Enterprise Maven extension. Older versions are incompatible with publishing access control and will no longer be able to publish build scans when it is enabled.

Use of build scan publishing access control requires extra setup for developers in the configuration of access keys. This may not be desirable for all organisations, particularly when the Gradle Enterprise server is only accessible within a private network.

Use of access keys to authenticate and authorize access to Gradle Enterprise from builds will expand in subsequent Gradle Enterprise releases.

Build scan publishing access control requires Gradle Enterprise Gradle plugin 3.1+ or Gradle Enterprise Maven extension 1.3+.

Inspect avoidance savings for individual builds

An “avoidance saving” is an estimate of the amount of time saved when execution of a Gradle task or Maven goal was avoided due to reuse of existing outputs. It is measured as the difference between the time taken to originally do the work, and the time taken to reuse it (e.g. download from remote build cache). For Gradle builds, outputs can be reused via incremental building and build caching, while for Maven builds build caching is the only avoidance mechanism.

The performance dashboard has visualized this metric across builds and as a single per-build metric since it was introduced. New in Gradle Enterprise 2019.4 is a more fine grained per-task and per-goal breakdown within an individual build scan.

Click on a task/goal details inspector to reveal the time saved by reusing its outputs.

The “Execution” tab of the “Performance” page also contains a breakdown of all avoidance savings for the given build, by type.

Analyzing and monitoring avoidance savings is an effective way to avoid build time regressions due to build or infrastructure changes. It can also be used to identify rare scenarios where avoidance mechanisms result in a net loss due to the time taken to transfer reusable outputs being greater than the time taken to create them.

Compare more aspects of Maven builds

Maven build comparison now includes captured custom values, Maven switches and infrastructure of the machine where the build ran.

This provides additional insight while analyzing the difference between two Maven build executions.

Improved failure dashboard failure classification

The failure dashboard introduced in Gradle Enterprise 2019.3 performs semantic analysis of build failures in order to classify build failures as verification (routine build feedback such as compilation failure) or non-verification (errors in build logic or build infrastructure).

Based on data volunteered by Gradle Enterprise users since its release, the classification model has been expanded and improved. A new mechanism has also been added that makes it simpler to craft error messages for correct classification.

Cacheability filtering in task/goal input comparison

The Gradle task and Maven goal inputs comparison now indicates prominently the cacheability of the task/goals with differing inputs.

In builds with many tasks/goals, this makes it easier to focus on cacheable tasks whose inputs are different. Inspecting non-cacheable tasks/goals is necessary when the root cause of an input difference is a task/goal that is a dependency of the cacheable task/goal that itself is not cacheable.

Run Gradle Enterprise on Red Hat® OpenShift®

The Kubernetes installation of Gradle Enterprise is now compatible with OpenShift.

Upgrade notes

If upgrading from a version of Gradle Enterprise prior to 2019.3, be sure to also consult the release notes for all interim versions.

Major upgrade of the Gradle Enterprise Gradle plugin

The Gradle Enterprise Gradle plugin was previously named and referred to as the “build scan” plugin. With the release of Gradle 6.0 and version 3.0 of this plugin, it has been renamed to the “Gradle Enterprise” plugin.

When used with Gradle 6 and later, the plugin is now a Gradle Settings plugin, and its ID has changed from “” to “com.gradle.enterprise”. When using Gradle 5.x, the plugin continues to be referred as the build scan plugin and is unchanged in how it is used.

Please see the Gradle Enterprise Gradle Plugin User Manual for more information and for upgrade guidance.

Increased storage requirements due to tests analysis

The new tests dashboard feature requires extra data indexing that increases disk usage. The exact amount is dependent on how many builds are captured and how many tests are executed. During testing, increases in disk usage ranged from 0.1% to 0.5%.

It is strongly recommended to enable active disk space management for all production installations of Gradle Enterprise at all times. If you have not yet enabled it, please consider doing so before upgrading.

Temporarily degraded performance due to data reindexing

Upon upgrading, a data reindexing process will be initiated in the background with Gradle Enterprise being usable for its duration. CPU usage will be increased and performance may be slightly degraded. For large installations storing many build scans, the reindexing process may take several hours. During this time some builds may be omitted from the performance, failure and test dashboards.


Dec 03, 2019
  • [FEATURE] Task/goal inputs comparison provides more detailed tooltips for changed files and directories
  • [FEATURE] Users can find in-app help for tests dashboard elements
  • [FIX] Maven performance page errors when no build cache operations were performed
  • [FIX] Gradle performance page does not indicate correct totals for certain early failure cases
  • [FIX] Gradle dependencies selected by capability don't have correct "requested" note
  • [FIX] Gradle dependencies page errors under certain circumstances
  • [FIX] Search filters inputs cannot be submitted with "enter" key on Safari
  • [FIX] User without viewing permission sees error page after logging in
  • [FIX] "Build scans" link in user menu is sometimes not visible when anonymous scans viewing is enabled
  • [FIX] Tests dashboard keeps unnecessary tables in database
  • [FIX] SMTP password is written in the Kubernetes configuration file as plain text
  • [FIX] Email about Gradle Enterprise backup is not generated
Nov 25, 2019
  • [FEATURE] Analyze test failure and performance over many builds
  • [FEATURE] Restrict publishing of build scans to authorized users
  • [FEATURE] Inspect avoidance savings for individual builds
  • [FEATURE] Custom values of Maven builds can be compared
  • [FEATURE] Switches of Maven builds can be compared
  • [FEATURE] Infrastructure of Maven builds can be compared
  • [FEATURE] Task/goal inputs comparison items can be filtered by cacheability
  • [FEATURE] Gradle settings plugins are displayed in build scans
  • [FEATURE] Kubernetes installation of Gradle Enterprise supports OpenShift
  • [FEATURE] Build failures can be reliably classified by use of definitive error message prefixes
  • [FIX] Goal/task inputs cannot be compared for different build tool versions
  • [FIX] External dependency task file inputs differing in file content are visualized confusingly
  • [FIX] Task/goals with ‘unknown cacheability’ are presented as ‘not cacheable’
  • [FIX] Failed task/goals are not displayed first on the timeline summary
  • [FIX] Ordering of build tags in performance dashboard is inconsistent with order in build scans
  • [FIX] Gradle 6 builds that fail very early cannot be displayed
  • [FIX] Build scan search criteria do not render reliably when resizing the browser window
  • [FIX] Build scan comparison controls in build scan search are not consistently displayed
  • [FIX] ANSI color codes are displayed in Maven failure page