Gradle Enterprise 2021.1

Test Distribution now makes better use of agents that become available during the execution of tests, allowing tests to complete sooner. Previously, agents were allocated immediately prior to the execution of a test suite and the individual tests assigned accordingly. Now, agents may be allocated during the execution of a test suite and be assigned tests that have not yet been executed.

This enhancement is available for both Gradle and Maven users, and is particularly effective when many Test Distribution enabled projects are being built concurrently and/or when builds contain many different Test Distribution enabled test suites that are executed concurrently.

Maven build scans now provide a “Dependency resolution” subsection within the “Performance” section that visualizes the dependency resolution activity within the build from the perspective of build overhead. This is particularly useful for identifying poor network performance or poor performance of an artifact repository as an area for potential optimization.

The activity can be isolated to that incurred to resolve the project dependencies (i.e. those that your application uses) and the Maven plugin dependencies (i.e. the dependencies of the Maven plugins used in your build). Due to limitations within current Maven versions, some activity cannot reliably be attributed to either project or plugin dependencies and is visualized in build scans in the “Other” category. All activity can be seen at once via the “All” category.

Maven dependency resolution activity occurs in parallel. As such, the total times shown indicate “serial time” (i.e. the sum of the time of each activity). While this cannot be used as a direct measure of how much wall clock time was spent during the build performing dependency resolution it can be used as a general indicator of overhead and as a relative indicator between two different build environments that may experience different network conditions.

Additionally, the performance and trends dashboards also now visualize the total serial time for “Dependency downloading” (i.e. how much time was spent downloading files during dependency resolution).

This allows identifying anomalies in this build metric across a set of builds and analysing the over-time trend of this metric for a set of builds.

The upcoming Gradle version 7 employs stricter requirements of task implementations and configuration before allowing performance optimizations such as incremental building and build caching to be used. Many such requirements were introduced during Gradle 6.x, but were not enforced and only resulted in deprecation warnings. Violation of these requirements with Gradle 7 will result in a build error. For new requirements that are added during the evolution of Gradle 7 and beyond, violations will result in execution optimizations for the task being disabled instead of a build error, along with deprecation warnings.

A new, specific, “caching disabled reason” has been added to Gradle build scans to allow more easily identifying tasks that have been subject to this restriction, which can be used as search criteria within the “Timeline” section.

When specifying the build start time criteria when searching for or analyzing a set of build scans, the time of day can now be specified for the beginning and end of the range. This allows more fine grained selection across multiple days, as well as restricting selection to within a single day.

The storage and processing of test data for visualization with the tests dashboard has been further optimized to provide results faster, particularly when analyzing test classes that execute many tests or that are executed many times in a build such as matrix or generated tests.

The data processing now makes much better use of multiple CPU cores when available. Making more CPU cores available to your installation may significantly improve the responsiveness of the tests dashboard. For assistance determining whether you would benefit from doing so, please contact Gradle Enterprise technical support.

The Gradle Enterprise Export API provides real time access to the build data that powers build scans and other build data visualizations and analysis, via a HTTP Server Sent Event interface. Previously, only HTTP basic authentication was allowed which is not compatible with a SAML based external identity provider. It is now possible to use the HTTP bearer token authentication scheme utilizing Gradle Enterprise access keys, for all types of accounts. Usage of this authentication scheme is strongly recommended over use of usernames and passwords.

Additionally, Gradle Enterprise allows Cross-Origin-Resource-Sharing (CORS) for requests authenticated via an access key. This allows the Export API to be accessed from a runtime environment that implements CORS access control, such as a browser or browser based Javascript runtime.

Please refer to the Gradle Enterprise Export API Manual for more information.

Gradle Enterprise allows using an LDAP server for user authentication and authorization. Previously, it was only possible to restrict LDAP users based on a DN prefix and/or group membership. It is now possible to specify an LDAP filter that must be satisfied by a user account before it can be used to authenticate with Gradle Enterprise.

The filter permits all accounts by default and can be configured via the “Administration” -> “Access control” section.

Gradle Enterprise allows creating and managing users within Gradle Enterprise itself and using an external identity provider via SAML or LDAP. User accounts created by Gradle Enterprise are now subject to basic password complexity requirements to discourage the use of easy to guess passwords. All existing passwords are unchanged and may continue to be used.

It is recommended that, wherever possible, an organizational identity provider is used for account authentication that provides organizationally compliant password management, instead of locally created accounts.