Gradle Enterprise 2019.4

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

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 “com.example.app.service.GreatFeatureBrowserTest” or “*BrowserTest” or “com.example.app.service.*”.

Learn more in this blog post.

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.

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.

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.

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.

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.

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