Free training on Gradle, Maven, and Develocity at DPE University Get started today
Gradle Enterprise 2022.3
Gradle Enterprise 2022.3 adds several new Build Scan™ features that make it easier to analyze and reason about build cache optimizations, along with a new deployment configuration option to utilize an S3-compatible store for Build Scan™ data that enables cheaper and faster large-scale deployments, and the option to utilize the same credentials and access control mechanisms for build cache access as is already used for Build Scan™ publishing and other build-time features, simplifying user management and build configuration.
Read on for more details of these and other new features.
Use version 1.15.5 of the Gradle Enterprise Maven extension, version 3.11.4 of the Gradle Enterprise Gradle plugin, version 1.6.14 of the Gradle Enterprise Test Distribution Agent, and version 13.1 of the Gradle Enterprise Build Cache Node for optimal usage of Gradle Enterprise.
Highlights
Discontinuation of Replicated-based installation options
In March 2022, Gradle Enterprise 2022.1 introduced a new installation approach based on Helm. The previous Replicated-based installation process was deprecated, with Gradle Enterprise 2022.3 – including its patch updates – being announced as the last version that would be installable via the Replicated-based process. It was also announced that installations based on the Replicated process would no longer be supported as of January 2023.
If you have not yet updated your installation to use the Helm-based process, you should do so soon.
This affects users deploying directly to a Kubernetes cluster, or using a single-host standalone installation. Users wanting to deploy to a single host and not wanting to use Kubernetes directly can use k3s as a single-host Kubernetes runtime, which abstracts away Kubernetes details for simplified deployments.
The adoption of Helm as the basis of installing Gradle Enterprise was motivated by feedback from users wanting to take advantage of the various tooling that has emerged around Helm as it has become a de facto standard. Organizations are increasingly familiar with these tools and prefer Helm-based workflows for installing and updating software.
A migration guide is available which is the best place to start learning more. If you have any questions or concerns about migrating, contact Gradle Enterprise technical support for assistance.
Programmatically fine-tune and extend build caching for Apache Maven™ builds
Previously, fine-tuning build caching for a Maven goal, or making a goal that is not cacheable out of the box cacheable, required configuration via XML. With version 1.15 of the Gradle Enterprise Maven extension, this can now be done programmatically which is often more convenient to author and maintain.
In the example below, the build caching configuration of test execution is enhanced to declare an additional input of a filtered view of the “src/test/specs” directory and using the “Relative path” normalization strategy.
BuildCacheApi buildCache = (BuildCacheApi) mavenSession.lookup("com.gradle.maven.extension.api.cache.BuildCacheApi");
buildCache.registerMojoMetadataProvider(context -> {
context.withPlugin("maven-surefire-plugin",
() -> context.inputs(inputs -> inputs
.fileSet(
"specs",
"src/test/specs",
fileSet -> fileSet
.include("**/*.feature")
.exclude("archive/**/*.feature")
.normalizationStrategy(MojoMetadataProvider.Context.FileSet.NormalizationStrategy.RELATIVE_PATH)
))
);
});
All customizations that were previously possible via XML can now be done programmatically, too. Please consult the Gradle Enterprise Maven extension User Manual for further information.
View selected Java toolchains of Gradle tasks
The Java toolchains feature introduced in Gradle 6.7 makes it much more convenient to compile, test and run JVM software with different Java versions or a different Java version than the version used to run Gradle. When using the upcoming Gradle 7.6, the exact toolchain selected for any task leveraging this feature is displayed in the Build Scan™ when inspecting task details in the Timeline section.
Group Gradle tasks and Apache Maven™ goals by type
Gradle tasks and Maven goals can now be grouped by type in the Timeline section of a Build Scan™, making it easier to reason about the potential of optimizing a particular task type or goal type.
Identify unintentionally not-cacheable tasks and goals
The Timeline section of both Gradle and Maven Build Scans allow filtering tasks and goals based on the “not-cacheable reason”. It is now possible to add negated criteria, to exclude non-cacheable tasks or goals that are not cacheable for a specific reason.
Inspect applied Apache Maven™ extensions
Maven extensions decorate and augment Maven builds with custom behavior. A Build Scan™ now visualizes the extensions applied to the build and the listener types they registered as the extension points they used.
Test Distribution and Predictive Test Selection are now part of the Gradle Enterprise Gradle plugin
Previously, using Test Distribution or Predictive Test Selection with Gradle required use of the Gradle Enterprise Gradle plugin and an additional separate Test Distribution plugin. As of version 3.11 of the Gradle Enterprise Gradle plugin, these features no longer require this additional plugin, simplifying configuration and updating.
When updating to version 3.11 of the Gradle Enterprise Gradle plugin, Test Distribution and Predictive Test Selection users can simply remove application of the “com.gradle.enterprise.test-distribution” plugin from their builds, leaving all other configuration as-is.
Please refer to the Gradle Enterprise Gradle Plugin User Manual for more information on using the plugin.
Additional “build cache performance” information available via the Gradle Enterprise API
The “build cache performance” endpoint of the Gradle Enterprise API has been enhanced in Gradle Enterprise 2022.3 with more information about why a Gradle task or Maven goal was not cacheable, along with the implementation type of the task or goal.
For Gradle builds, information about the type of remote build cache being used is now also available.
For more information, see the API release history.
Manage build cache access control via Gradle Enterprise identity management
Gradle Enterprise has for some time supported use of “access keys” for authenticating build users for the publishing of Build Scans, use of Test Distribution and Predictive Test Selection. As of Gradle Enterprise 2022.3, this same credential can be used to authenticate build cache access, making build cache access control and build configuration simpler and more robust.
To use access-key-based build cache access control, Gradle users will need to update to Gradle Enterprise Gradle plugin version 3.11 and update their build configuration to use the Gradle Enterprise specific build cache connector. Maven users will need to update to version 1.15 of the Gradle Enterprise Maven extension and remove any specified username and password (more information). Gradle Enterprise administrators will also need to assign the new “Build cache read” or “Build cache write” permissions to users via Gradle Enterprise access control configuration. Any additional remote build cache nodes must also be updated to version 13 to allow access-key-based access control.
The existing username and password build cache access control mechanism has not been removed, and will continue to be supported for some time. Administrators wanting to exclusively use access keys to control build cache access can remove any configured username and password credentials for each build cache node within Gradle Enterprise.
Faster and cheaper Build Scan™ data storage via S3-compatible object stores
Gradle Enterprise now provides the option of using an Amazon S3-compatible object store to store Build Scan™ data, enabling faster and cheaper storage of more data.
By default, Gradle Enterprise stores Build Scan™ data in the configured Postgres database. This has the advantage of being simple to deploy and operate. It has the disadvantage of being expensive and difficult to scale for larger installations. Utilizing an additional S3-compatible store is a compelling deployment option for larger installations that produce large volumes of data.
This deployment option is available for new and existing installations. Please see the Gradle Enterprise Admin Guide for more information.
Gradle Enterprise has been extensively tested with Amazon S3 service but is also intended for use with other S3-compatible stores such as MinIO or Google Cloud Storage. If you wish to use a service other than Amazon S3, please contact Gradle Enterprise technical support.
Administrators can delete a particular Build Scan™
Gradle Enterprise users with the “Administer Gradle Enterprise” permission can now delete individual Build Scans, via a link on the left navigation menu.
Upgrade notes
Installations using “additional trust“ SSL configuration settings with multiple certificates should bypass 2022.3 and install 2022.3.1
If your installation is configured with additional certificates to enable trusted SSL connections, you should ensure to upgrade to 2022.3.1 and not install 2022.3. If you are unsure whether your installation will be affected by this issue, upgrading directly to 2022.3.1 is recommended.
Gradle Enterprise Test Distribution Gradle plugin has been subsumed by the Gradle Enterprise Gradle plugin
The Gradle Enterprise Test Distribution Gradle plugin is no longer required to use Test Distribution or Predictive Test Selection as this functionality is now provided by the Gradle Enterprise Gradle plugin.
When updating to version 3.11 of the Gradle Enterprise Gradle plugin, Test Distribution and Predictive Test Selection users can simply remove application of the “com.gradle.enterprise.test-distribution” plugin from their builds, leaving all other configuration as-is.
Please refer to the Gradle Enterprise Gradle Plugin User Manual for more information on using the plugin.
Changes
- [FIX] - Data deletion fails when attempting to delete more than one object when using Google Cloud Storage
- [FIX] - Data ingestion performance on heavily loaded systems may be constrained by object storage connection limit
- [FIX] - Task details links in comparison view does not focus task in Build Scan view
- [FIX] - Task change type filter in task inputs comparison does not filter
- [FIX] - Navigating to next page in console log with focus on a line yields an error
- [FIX] - Build cache serves the wrong status when the corresponding file is missing
- [FIX] - Database passwords change between helm invocations, causing unnecessary restarts
- [FIX] - Test distribution content digest mismatches are reported without enough detail to troubleshoot
- [FIX] - Evicting entries from build cache nodes with very high turnover does not complete
- [FIX] - Clicking a task in the timeline chart does nothing when tasks are grouped by type
- [FIX] - S3 connection test ignores draft app config parameters
- [FIX] - No placeholder avatar is shown when there is no associated Gravatar image
- [FIX] - Expanding and collapsing details in timeline view may cause error when grouping items by type
- [FIX] - Disk usage may grow unbounded after ingesting elevated volumes of new build scan data
- [FIX] - Build cache node health check displays misleading signed out status on network failure contacting node
- [FIX] - Performance of Helm-based standalone installation is degraded due to misconfigured memory management
- [FIX] - Kubernetes pods fail to start in environments that change the default user group ID
- [FIX] - Extension expiration dates are not clearly visible on license page
- [FIX] - Incorrect role membership settings are displayed when changing identity provider after changing role membership mode
- [FIX] - Kubernetes pods do not display termination reason when failing to start due to invalid license
- [FIX] - HTTP proxy authentication cannot be configured via the user interface
- [FIX] - Non-proxy-host values containing an asterisk cannot be configured via the user interface
- [FIX] - Test distribution and build cache cannot be used in network policy enforcing Kubernetes environments
- [FIX] - Attempting to start an instance with an expired license causes hard-to-diagnose application crash
- [FIX] - Database backups may fail to restore in some cases
- [FIX] - Build scan list links from previous Gradle versions may not be viewable
- [FIX] - Installations configured with > 1 additional trust certificate cannot be upgraded to 2022.3
- [FIX] - Pages may not render when using Safari <= 15.4
- [FIX] - Auto-configure of deployment health checks fails on Google Kubernetes Engine
- [FIX] - Inconsistent build cache configuration warning message does not indicate difference
- [FIX] - Editing test class name filter on test method details page in tests dashboard may produce error
- [NEW] - PTS usage and simulator dashboards show mean build duration
- [NEW] - Administrators can delete individual Build Scans
- [NEW] - Build Scan data can be stored in an S3-compatible store
- [NEW] - Maven build cache configuration can be specified programmatically
- [NEW] - Applied Maven extensions are visualized in Build Scans
- [NEW] - Java toolchains selected by tasks are visualized in Gradle Build Scans
- [NEW] - Build cache performance API models indicate task and goal not-cacheable reasons
- [NEW] - Build cache performance API models indicate task and goal types
- [NEW] - Build cache performance API models indicate Gradle remote cache configuration
- [NEW] - Build cache access control can be managed by Gradle Enterprise identity management
- [FIX] - Permissions errors are generated during container startup on `lost+found` directories when amending file permissions
- [FIX] - Pagination controls exhibit surprising behavior
- [FIX] - Non-airgapped installations cannot start when outbound internet access requires connecting through a HTTP proxy
- [FIX] - Application may fail to restart due to database migrator failure