Free training on Gradle, Maven, and Develocity at DPE University Get started today
Gradle Enterprise 2023.2
Gradle Enterprise 2023.2 brings greater observability and insights to Test Distribution usage for Gradle and Apache Maven™ builds, new Predictive Test Selection usage options for maximizing build time savings, build insights and build caching support for the Bazel build tool, and introductory integration for the sbt build tool.
Read on for more details of these and other new features.
Use version 1.18.1 of the Gradle Enterprise Maven extension, version 3.14.1 of the Gradle Enterprise Gradle plugin, version 0.9 of the Gradle Enterprise sbt plugin, version 2.0.3 of the Gradle Enterprise Test Distribution agent, and version 16.0 of the Gradle Enterprise Build Cache node for optimal usage of Gradle Enterprise.
Use the latest versions of the Gradle Jenkins plugin, Build Scan plugin for TeamCity, and Gradle Enterprise Bamboo plugin for optimal integration of your CI provider with Gradle Enterprise.
Highlights
Fine-grained Test Distribution observability in Build Scans
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.
Predictive Test Selection profiles
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 “remaining tests” mode
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.
Improved handling and observability of too-large cache entries
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.
Build insights and build caching for the Bazel build tool
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.
Build Scan® for sbt, the Scala build tool
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.
Upgrade notes
After upgrading your Gradle Enterprise server to the most recent version, it is recommended to upgrade your builds to use the latest version of the Gradle Enterprise Gradle plugin, Gradle Enterprise Maven extension, Gradle Enterprise sbt plugin, Gradle Enterprise Test Distribution agent, and Gradle Enterprise Build Cache node. Using the latest versions of all components ensures that you benefit from security updates, bug fixes, and feature enhancements. Please check the version compatibility matrix for further reference.
It is also recommended to update your configuration of the Gradle Jenkins plugin, Build Scan plugin for TeamCity, and Gradle Enterprise Bamboo plugin to reference the latest version of the Gradle Enterprise Gradle plugin.
Gradle Enterprise installations with multiple replicas must follow the documentation before upgrading to 2023.2. With this release, it is essential to scale down the replicas to one before upgrading.
Pre-upgrade database configuration required for superuser-less user-managed databases
Gradle Enterprise installations can use an embedded database provided as part of the installation, or a user-managed database for superior performance and operability. When using a user-managed database, Gradle Enterprise can be configured with superuser access to the database so that it can initialize and configure the database appropriately. Alternatively, this initialization and configuration can be executed manually, avoiding the need to provide Gradle Enterprise with superuser access to the database.
For installations using the superuser-less approach, new configuration requirements in Gradle Enterprise 2023.2 necessitate manually executing an updated configuration script as part of the upgrade.
If your installation uses the superuser-less approach, please contact Gradle Enterprise support to obtain the new configuration scripts before upgrading. If you are unsure whether your installation uses this approach and requires this extra upgrade step, please contact Gradle Enterprise support.
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. The reindexing process may take several hours for large installations storing many Build Scan items. During this time, some builds may be omitted from cross-build data visualizations. Recent builds are prioritized, making their data available sooner.
Predictive Test Selection is temporarily unavailability after upgrading
The introduction of selection profiles in this release requires re-analyzing build history, which is initiated automatically after upgrading. Attempting to use Predictive Test Selection while this occurs will result in all tests being selected for execution. The duration of this process depends on the amount of build history stored by your installation and the availability of CPU resources. It is estimated to take ~24 hours for an installation with a build history of 6 months of 60,000 builds per week and eight processor cores. Due to this, it is recommended that installations using Predictive Test Selection are upgraded at the end of the week to allow this process to complete over the weekend. A banner will be displayed on the Predictive Test Selection dashboard while this re-analyzing occurs.
Removal of anonymous access to build cache configuration
This release removes the ability to allow anonymous users to access or change build cache configuration. This functionality was deprecated in the 2023.1 release.
Ceased support for pre-2021.3 versions of Test Distribution Agent, Test Distribution Gradle Plugin, and Gradle Enterprise Maven Extension (for use with Test Distribution)
Using Test Distribution with versions older than Test Distribution Gradle plugin 2.2, Gradle Enterprise Maven extension 1.11, or Test Distribution agent 1.6 is no longer supported. These versions were introduced before Gradle Enterprise 2021.3 and use a communication protocol that required manually specifying JVM arguments on JDK 17 and later. Support for these versions was deprecated with 2023.1 and is removed with this release. Please check your builds and agents and update them as necessary before upgrading to 2023.2.
Use of custom path prefix for Build Scan data is S3 storage is now deprecated
Configuring a custom path prefix to use within an S3 bucket for storing Build Scan data is no longer possible. Any existing custom prefix settings will continue to be respected after upgrading to the latest version.
Customers using a custom prefix are advised to contact Gradle Enterprise support for guidance on migrating to the non-custom path.
New encryption key for SAML assertion
This release introduces a separate encryption key for decrypting SAML assertions and requires updating the identity provider configuration with the metadata generated by this version of Gradle Enterprise if `Require encrypted SAML assertion` is enabled.
Gradle Enterprise Helm Chart upgrade notes
- The log-forwarder container CPU usage was decreased (cpu requests: from 500m to 250m, cpu limits: from 1000m to 500m).
- The gradle-enterprise-operator container resources were increased (cpu requests: from 50m to 250m, cpu limits: from 250m to 512m, memory requests: from 256Mi to 512Mi, memory limits: from 512Mi to 1024Mi)
- For standalone installations, the gradle-node-monitoring container was changed from DaemonSet to Deployment.
You can find resource requirements for cluster installations here and standalone installations here. If you want to compare all helm changes between your currently installed version and the version you are upgrading to, you can use the helm template command for each version and then compare the two templates.
Changes
- [FIX] Keycloak and monitoring components cannot be configured with public IP addresses
- [FIX] 2023.2.1 Export API emits invalid JSON
- [NEW] Embedded database upgrade to Postgres 12.16
- [FIX] Filtering by executor type or name in Slowest Tests view causes error
- [FIX] Viewing predecessors of planned artifact transform causes error
- [FIX] Build scan text queries return incorrect results when using multiple custom value wildcard values
- [FIX] View Predictive Test Selection usage link is broken on test class details page
- [FIX] Test task details link for builds with older Gradle Enterprise plugins does not work
- [FIX] Export API performance is reduced when using object storage for Build Scan data
- [NEW] Fine-grained Test Distribution observability in Build Scans
- [NEW] Predictive Test Selection profiles
- [NEW] Predictive Test Selection “remaining tests” mode
- [NEW] Improved handling and observability of too-large cache entries
- [NEW] Build insights and build caching for the Bazel build tool
- [NEW] Build Scan® for sbt, the Scala build tool
- [NEW] Access control roles can also be locally assigned when using IdP-assigned roles
- [FIX] When deleting an access control role, the role member count does not include identity provider managed users
- [FIX] - Outcomes of Gradle planned transform nodes with avoided executions are not accurate
- [FIX] - Gradle task creation performance statistics are incorrect when using configuration cache
- [FIX] - Gradle task failures of type VerificationException are not classified as verification failures
- [FIX] - Anonymous users can be granted permission to configure build caches
- [FIX] - SCIM requests from Okta fail with authentication errors
- [FIX] - Support bundle generation performance and stability improvements