Gradle Enterprise 2022.3

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Gradle Enterprise users with the “Administer Gradle Enterprise” permission can now delete individual Build Scans, via a link on the left navigation menu.