Gradle Enterprise 2023.3

This feature allows organizations to share a single Gradle Enterprise installation while ensuring that data and information about individual projects are restricted to an appropriate subset of users and teams, respecting organization information-sharing boundaries. This includes Build Scan® data, Build Cache data, test acceleration features (including Test Distribution and Predictive Test Selection), and analytics and insights derived from build data for Gradle, Apache Maven™, sbt, and Bazel.

Project-level access control requires registering a “project ID” for each project with Gradle Enterprise, assigning it to one or more project groups, and then assigning users to project groups (either directly or via SAML or LDAP role mappings). Users may only perform an action (e.g. viewing a Build Scan) for data related to a project if they are associated with the project via a project group. 

To leverage project-level access control builds must be configured with a project ID as part of their Gradle Enterprise configuration. This project ID is not a secret value and can be safely checked into version control. For environments where Gradle Enterprise functionality is automatically applied to many projects (such as via the Jenkins Gradle plugin, which also works for Maven builds) without any checked-in build configuration, the project ID can be specified via the build environment.

See the appropriate manual for your build tool for instructions on how to specify the project ID:

• Gradle Enterprise Gradle Plugin User Manual – Configuring project identifier
• Gradle Enterprise Maven Extension User Manual – Configuring project identifier
• Gradle Enterprise sbt Plugin User Manual – Configuring project identifier
• Gradle Enterprise Bazel Plugin User Manual – Configuring project identifier

Projects and project groups can be created and managed manually within the Gradle Enterprise user interface, or the Gradle Enterprise API can be used to automate this step, potentially integrating with an organization’s project registry or project provisioning workflows. 

The related API operations are currently “beta” and may change due to user feedback over the subsequent major releases.

Project-level access control is disabled by default. See the Project-level access control in the Gradle Enterprise Administration Manual for Helm Installations for details on enabling and migrating to project-level access control.

An estimate of the actual build time contributed by downloading dependencies is now available in a Build Scan for Gradle and Maven. Previously, only a “serial time” number was observable which is the sum of time taken for all dependency downloading network operations. As dependency downloading frequently occurs in parallel with other requests and other types of build work, this number is typically significantly higher than the actual effect on elapsed, or “wall clock”, build time. The new wall clock time estimate provides a more insightful representation of the build time cost of downloading dependencies.

For many organizations, dependency downloading significantly contributes to CI build times due to short-lived or ephemeral build environments, where a lack of local dependency caches causes each build to download excessive amounts of data from slow and often unreliable artifact repositories. Organizations can use the new wall clock time estimates to assess this build time cost and quantify any future improvements or optimizations to CI or artifact repository infrastructure.

For Gradle builds, the per-build time can be found in the “Performance → Network activity” section.

For Maven builds, the per-build time can be found in the “Performance → Dependency resolution” section. 

The wall clock dependency downloading time can be visualized across builds via the “Performance dashboard”.

It can also be visualized in aggregate via the “Trends dashboard”.

Building on the improved observability of Gradle artifact transforms in Gradle Enterprise 2023.1, it is now possible to navigate to the logs for one particular artifact transform from the timeline by clicking on “View transform in console log”.

By leveraging the charts in the Trends and Performance dashboards you can now easily comprehend important aspects of build performance across many sbt builds.

The savings chart on the Predictive Test Selection (PTS) usage dashboard has been improved to provide two new insights.

The “Serial test time saved” number is now qualified with an overall percentage indicating how this number relates to the total serial test time where PTS was enabled.

The “Savings Potential” number indicates the amount of serial test time that PTS would have saved if it were enabled for all tests, providing context on how much more time could be saved by enabling PTS for more tests and more builds.

Gradle Enterprise 2023.1 introduced the ability to search for builds matching criteria via a new query language. This release introduces several new fields and a convention for build-tool-specific fields, that implicitly apply the corresponding build tool as a criterion. Thus, the advanced search query gradle.requestedTasks:verify selects only Gradle builds, whereas the query maven.requestedGoals:verify selects only Maven builds.

It is now possible to use an advanced search query to filter builds according to the applied version of the Gradle Enterprise plugin or extension, depending on the build tool, by using the fields gradle.pluginVersion, maven.extensionVersion, or sbt.pluginVersion.

There are new build-tool-specific fields: gradle.rootProjectName, maven.topLevelProjectName, and sbt.rootProjectName. The previous rootProjectName field, a tool-agnostic version of the same concept, has been renamed to project. 

There are new build-tool-specific fields gradle.requestedTasks, maven.requestedGoals, bazel.requestedTargets, and sbt.requestedTasks that complement the existing requested.

See the advanced query language reference for further details.

Previously, the /api/builds API endpoint allowed listing all known builds and observing new builds as they happen. Now, it can also list and observe only builds matching specific criteria, expressed as an advanced search. In many cases, this avoids making extra API calls to determine whether a given build is a build of interest before continuing with processing, making programs using the API simpler and faster.

Features recently introduced in the Gradle GitHub Action and Gradle Enterprise GitLab templates make it easier to enable Gradle Enterprise for GitHub Actions and GitLab CI builds, without requiring any modification to existing build scripts.

This functionality is beneficial for organizations with an existing set of diverse projects. It makes the insights of a Build Scan available without requiring project owners to make changes to their build logic, limiting these changes to GitLab CI or GitHub Actions configuration files. By connecting more projects to Gradle Enterprise, teams can better monitor build performance and failure rates across all projects.

Note: Gradle GitHub Action is only able to instrument Gradle builds.

Similar integrations already exist for Jenkins, TeamCity and Bamboo.

Connecting hundreds or thousands of Gradle and Maven projects to Gradle Enterprise for the first time can be time-consuming. The canonical way requires modifying the existing build configuration settings, which is impractical at scale. That’s why we collaborated with OpenRewrite from Moderne to create pull requests to update all repositories automatically.

Contact your customer success representative if you’d like to learn more.

A new init goal has been introduced to quickly set up the Gradle Enterprise Maven extension on any given project. Running the following command will create or update .mvn/extensions.xml to add the Gradle Enterprise Maven extension and configure it for use with the specified server.

mvn com.gradle:gradle-enterprise-maven-extension:init -Dgradle.enterprise.url=https://gradle-enterprise.mycompany.com

Please see the Gradle Enterprise Maven Extension User Manual for more information.

In addition to the previously supported Amazon S3, application data can now be stored in Azure Blob Storage, Google Cloud Storage and other S3-compatible stores. This makes using object storage available to installations in Google Cloud Platform and Microsoft Azure.

An evolved implementation of the build cache service is under active development. It is available as an opt-in beta for this release and replaces the existing service when enabled. It supports horizontal scaling of read-write instances for cluster deployments and leverages object storage for simpler persistence management. 

Opting into the new beta Build Cache service is suitable for users getting started with Gradle Enterprise who want to simplify their deployment configurations, or for existing users particularly interested in increased redundancy and availability. 

Please contact Gradle Enterprise support for information and guidance on enabling this feature.