Gradle Enterprise 2023.2

Build Scan now provide detailed information about Test Distribution usage for Gradle and Apache Maven™ builds, including build configuration, remote worker utilization, estimates of time saved, and network overhead.

When viewing the “Tests Overview”, the build’s tests can be filtered by whether they were executed locally or remotely and by the particular agent, making it easier to identify and debug remote-only test issues.

Inspecting a Gradle test task or Maven test goal in the overview shows whether Test Distribution was enabled, how many remote executors were used, and an estimate of the time saved.

Clicking a Gradle test task or Maven test goal in the overview navigates to a new page that displays its general configuration and tests. The Test Distribution tab of this page provides the configuration specific to Test Distribution, performance characteristics such as the number of requested/used executors, and file transfer overhead.

This release introduces the concept of “profiles”, which influence the number of tests that will be selected for execution by Predictive Test Selection. Gradle Enterprise offers three predefined selection profiles: Conservative, Standard, and Fast. The selection profile can be configured for each Gradle test task or Maven test goal.

The Standard profile is the default and provides the same experience as previous versions of Gradle Enterprise, where the selection profile was not configurable. It aims to strike a good balance between saving time and relevant test coverage. 

The Conservative profile will often consider more tests to be relevant than the Standard profile,  which reduces the likelihood of not selecting a test that would fail, but saves less time.

The Fast profile will often consider fewer tests to be relevant than the Standard profile, which saves more time, but increases the likelihood of not selecting a test that would fail. 

The Predictive Test Selection Simulator shows the simulated results of the different profiles, making it easy to assess their impact.

Predictive Test Selection accelerates builds by selecting the most relevant subset of tests for execution based on test history and code changes, skipping tests deemed non-relevant. A typical usage pattern is to enable it for early and frequent QA stages, such as pre-merge pull request quick feedback, and not apply Predictive Test Selection to later and less frequent extended coverage QA stages, such as nightly or pre-release builds, to ensure that all tests are ultimately executed. 

Before this release, ensuring that all tests are ultimately executed could only be achieved by completely disabling Predictive Test Selection for later QA stages, which would also execute tests previously selected by an earlier build that enabled Predictive Test Selection. The new “remaining tests mode” avoids this waste by not executing tests that were executed and passed in earlier builds and only executing the “remaining” tests.

Instead of disabling Predictive Test Selection for extended coverage QA stages, the “remaining tests mode” is recommended as it achieves the same result in ensuring that all tests will ultimately be executed for a given change while avoiding executing any given test more than once for a given change.

The Predictive Test Selection “mode” can be configured as part of the build configuration or via command line arguments. Please consult the reference documentation for Gradle or Maven for more information.

The Gradle Enterprise Build Cache for Gradle and Maven enforces a maximum entry size. Before this release, attempting to store an entry that exceeded this size would be treated as an error and prevent the build from using the remote cache for the rest of the build. Now, this is not treated as an error condition, and the upload attempt is avoided entirely. 

This can be observed in a Build Scan as a “Rejected store”, when viewing the Build cache performance overview.

It can also be observed when inspecting an individual Gradle task or Maven goal via the Timeline section.

The “build cache performance” Gradle Enterprise API endpoints (Gradle,  Maven) also indicate “Rejected store” outcomes.

This release introduces Gradle Enterprise’s support for build caching and improves build insights for the Bazel build tool.

A Gradle Enterprise installation can now be used as a remote store and build cache for Bazel builds in addition to Gradle and Maven builds and managed similarly, including replication to additional distributed build cache nodes. 

The Timeline section of a Bazel Build Scan now provides a swimlane-style visualization of the build’s actions, richer information about each action, and more fine-grained filtering controls.

Please see the Gradle Enterprise Bazel Configuration Guide for more information on configuring a Bazel build to integrate with Gradle Enterprise.

Gradle Enterprise now integrates with sbt, the go-to build tool for Scala projects.

This first release provides basic Build Scan® functionality, with several build metrics that help you understand, debug, and optimize your sbt builds. You can track how often a project is built, know on which machine a given build was executed and how long it took, discover usage patterns (such as interactive vs batch execution) or the sbt versions in use across various projects, and investigate build and test failures.

The Gradle Enterprise sbt plugin is required to publish a Build Scan. The plugin is considered beta for this release of Gradle Enterprise. Future releases will expand the functionality provided and may include incompatible changes.

You can publish an sbt Build Scan directly to the free scans.gradle.com service. If you are interested in connecting your sbt builds to your Gradle Enterprise installation, please contact your customer success representative.