Gradle Enterprise is now Develocity. Learn more about our rebrand here.
Gradle Enterprise 2023.2
Develocity 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 Develocity Maven extension, version 3.14.1 of the Develocity Gradle plugin, version 0.9 of the Develocity sbt plugin, version 2.0.3 of the Develocity Test Distribution agent, and version 16.0 of the Develocity Build Cache node for optimal usage of Develocity.
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. Develocity 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 Develocity, 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 Develocity 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.
This release introduces Develocity’s support for build caching and improves build insights for the Bazel build tool.
A Develocity 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 Develocity Bazel Configuration Guide for more information on configuring a Bazel build to integrate with Develocity.
Develocity 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 Develocity sbt plugin is required to publish a Build Scan. The plugin is considered beta for this release of Develocity. 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 Develocity installation, please contact your customer success representative.
After upgrading your Develocity server to the most recent version, it is recommended to upgrade your builds to use the latest version of the Develocity Gradle plugin, Develocity Maven extension, Develocity sbt plugin, Develocity Test Distribution agent, and Develocity 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 Develocity Bamboo plugin to reference the latest version of the Develocity Gradle plugin.
Develocity 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
Develocity 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, Develocity 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 Develocity with superuser access to the database.
For installations using the superuser-less approach, new configuration requirements in Develocity 2023.2 necessitate manually executing an updated configuration script as part of the upgrade.
If your installation uses the superuser-less approach, please contact Develocity 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 Develocity support.
Temporarily degraded performance due to data reindexing
Upon upgrading, a data reindexing process will be initiated in the background, with Develocity 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 Develocity Maven Extension (for use with Test Distribution)
Using Test Distribution with versions older than Test Distribution Gradle plugin 2.2, Develocity Maven extension 1.11, or Test Distribution agent 1.6 is no longer supported. These versions were introduced before Develocity 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 Develocity 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 Develocity if `Require encrypted SAML assertion` is enabled.
Develocity 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.
- [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 Develocity 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