Gradle Enterprise 2023.1

The Timeline view of a Gradle Build Scan™ now visualizes the time spent executing artifact transforms for project artifacts and provides identifying information about the transformations. This is particularly relevant for Android builds as artifact transforms are often a significant portion of the work performed.

Artifact transforms are a concept from dependency management. When Gradle resolves artifacts for a configuration and finds that they are not in the required format, Gradle can convert them to the requested format by running artifact transforms. Users do not directly request these transforms; if a task requires artifacts as input, Gradle runs the appropriate transforms before the task executes. For project artifacts declared as file inputs, Gradle schedules their transforms between relevant tasks or other units of work in the execution phase. Artifact transforms can depend on tasks or other transforms and can even run in parallel to tasks within the same project.

Artifact transform execution can fail as well. Depending on how the task consumes the transformed artifacts, this may or may not cause the build to fail. Regardless of the build outcome, any failures during the execution of artifact transforms are displayed on the Failure page and the Failures dashboard, providing developers with visibility into any issues that may arise during the build process.

Upcoming releases of Gradle Enterprise will expand on this new functionality to provide insights on build cache effectiveness of transforms as well as other finer-grained performance insights.

The new advanced search feature allows specifying search criteria via a query language on all dashboards. This makes searching for a Build Scan™ and defining data sets for analysis more concise and convenient, once you are familiar with the intuitive syntax. It can be used to perform searches that are not possible with the form-based basic search interface due to the ability to arbitrarily combine logical operators such as “not” and “or”.

Click the (?) icon next to the “Query” label in one of your dashboards after toggling “Advanced search” for a complete reference of all language syntax and available field names. 

As this is the first version of the advanced search feature, certain syntactic aspects may change in upcoming releases based on your feedback.

The Predictive Test Selection simulation dashboard now provides a summary breakdown into the reasons why tests were unavoidable, i.e. they would have been selected if Predictive Test Selection were actually used.

This summary helps when examining simulation results and reasoning about variance in savings potential across builds and Predictive Test Selection efficacy in general.

Moreover, to help find test tasks/goals with incorrect predictions, the table of tasks/goals can now be filtered to show only those rows with incorrect predictions:

The new Apache Maven Build Cache extension from the Apache Maven Project provides an alternative build caching approach and implementation for Maven 3.9 and later. This is different from the Gradle Enterprise Extension for Apache Maven that brings Gradle Enterprise features such as Build Scan™, Build Caching, Predictive Test Selection, and Test Distribution to Maven 3.3.1 and later.

Expect a detailed analysis of the differences and pros and cons of the different approaches from the Gradle Enterprise team in the near future.

To make it easier to experiment with this new extension from the Apache Maven Project, it can be used with Gradle Enterprise and Gradle Enterprise remote build cache nodes, leveraging the same access control and replication configuration. This can be achieved by using https://«server»/cache-maven as the remote server address, where «server» is the hostname of your Gradle Enterprise server or remote build cache node.

The XML file produced by this new extension is also viewable as part of the Build Scan™ in the Build cache section of the Performance view. This file provides a high-level overview of the build cache outcomes for the new extension.

Roles in Gradle Enterprise have been revamped to make it easier to manage permissions across a large set of users. 

Administrators can now create custom roles to represent different personas within the organization (such as “Developer”, “Productivity Engineer”, or “Administrator”), granting appropriate permissions to each role. When using an external Identity Provider via LDAP or SAML, each role can then be mapped to a role attribute value provided by the external system.

When upgrading from previous versions, new roles are automatically created that convey the same permissions as the previous single-permission roles defined by the system. This means that the access control configuration is unchanged after upgrading. However, it is recommended that you review your roles and their configuration after upgrading and take the opportunity to simplify the configuration by creating persona-based roles. 

The System for Cross-domain Identity Management (SCIM) standard enables external identity providers to proactively notify service providers, such as Gradle Enterprise, when changes are made to a user’s account or role memberships. Without SCIM automation in place, service providers only become aware of user changes the next time they sign in to the application via the identity provider.

All users leveraging external user management via LDAP or SAML should enquire whether their identity provider supports the SCIM standard and, if so, register Gradle Enterprise as a SCIM-enabled service provider to benefit from automated user deprovisioning and role-assignment modifications. 

Please refer to the Gradle Enterprise Administration Manual for more information.

Previously, build cache installations with millions of cache entries and anything less than a very fast SSD disk available could suffer from slow startup times and non-negligible IO overhead during startup and steady-state operation. Now, internal cache indexes and metadata are stored in an alternative format that reduces administrative IO, at the expense of using slightly more disk space. 

After upgrading, such installations should notice significantly faster startup and reduced IO overhead. Installations with caches containing less than millions of cache entries or using very fast disks are unlikely to notice a significant difference. 

This change applies to the built-in build cache node of Gradle Enterprise 2023.1 as well as version 15 of the separately deployable build cache node.

The recent introduction of the Gradle Enterprise Bamboo plugin makes it easier to enable Gradle Enterprise for all CI builds without needing to edit any Gradle build scripts or Maven POM files.

This functionality is beneficial for organizations with an existing set of diverse projects. It makes the profound insights of a Build Scan available without requiring project owners to make any changes. It allows teams to monitor build performance and failure rates across all projects.

The plugin adapts to various Gradle and Maven versions and usage patterns. It supports any explicit Gradle Enterprise configuration in projects, such as additional project-specific build tags and metadata.

The plugin is available via Atlassian Marketplace.

Similar plugins already exist for Jenkins and TeamCity. Plugins for additional CI providers are intended in the future.