Gradle Enterprise 2021.1

Gradle Enterprise 2021.1 makes Test Distribution faster by better utilizing agents that become available during execution of tests, provides insight into Maven dependency resolution activity and network requests, allows selecting builds for analysis by build time with minute granularity, and more.

Read on for more details of these and other new features.

Use version 1.9.2 of the Gradle Enterprise Maven extension, version 3.6.1 of the Gradle Enterprise Gradle plugin, version 2.0.3 of the Gradle Enterprise Test Distribution Gradle plugin, and version 1.4.1 of the Gradle Enterprise Test Distribution Agent for optimal usage of Gradle Enterprise.

Highlights

Faster testing with Test Distribution via better agent utilization

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.

Test Distribution is available since Gradle Enterprise 2020.5 as a preview of the Test Distribution extension. Depending on your usage license, this new functionality may not be available to your installation when it is no longer in feature preview. If you have questions regarding this matter, please contact Gradle Enterprise support.

Observe dependency resolution overhead for Maven builds

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.

This feature requires Gradle Enterprise Maven Extension 1.9+.

Identify Gradle 7 optimization-disabled tasks

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.

Find and analyze build scans by build start time with minute granularity

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.

Faster test analysis with the tests dashboard

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.

Access the build data Export API via access key

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.

Restrict allowed LDAP accounts by user filter

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.

Increased password complexity requirements for local user accounts

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.

Upgrade notes

If upgrading from a version of Gradle Enterprise prior to 2020.5, be sure to also consult the release notes for all interim versions.

Temporarily degraded performance due to data reindexing

Upon upgrading, a data reindexing process will be initiated in the background with Gradle Enterprise being usable for its duration. CPU usage will be increased and performance may be slightly degraded. For large installations storing many build scans, the reindexing process may take several hours. During this time, some builds may be omitted from cross-build data visualizations. Recent builds are prioritized, making their data available sooner.

New Replicated admin console version

This release requires a new Replicated admin console version.  If you have an airgapped installation, please follow steps 4-6 in the installation section of the admin manual to install the new version.  For non airgapped installations, there are no extra steps to perform.

Public access to Keycloak endpoints

Previously, public access was required to employ a workaround for Kubernetes installations when Keycloak was running on a node with an IP address that was not considered private (10.x.x.x, 192.168.x.x, 172.16.x.x).  The workaround was to post process the deployment manifest and update keycloak.admin.api.address and keycloak.private.address in the the gradle-env-vars-config to use the public host address.  This workaround is no longer required and the post processing step can be removed.

Changes

May 10, 2021
  • [NEW] - Replicated version has been upgraded to 2.51.3
  • [FIX] - Build cache node communication with Gradle Enterprise does not follow redirects
  • [FIX] - Titles of access keys cannot be edited
  • [FIX] - Backups may fail when other process share destination directory
  • [FIX] - Daily data maintenance may be delayed on installations processing many build scans
  • [FIX] - Access control functions do not work when components are deployed with public network addresses
  • [FIX] - Keycloak token exchange endpoint isn't accessible via public address
Apr 16, 2021
  • [FIX] - External login provider button appears disabled
  • [FIX] - Multiple lines of test logging output cannot be highlighted
  • [FIX] - Gradle dependency-resolution during configuration lifecycle callbacks is not shown as during configuration
  • [FIX] - Different parts of Gradle Enterprise show different favicons
  • [FIX] - Gradle builds with non-executed tasks finalized-by an executed task cannot be viewed in the Timeline section
Apr 08, 2021
  • [FIX] - Gradle timeline shows incorrect build cache activity for tasks that are never up-to-date.
  • [FIX] - Failure dashboard queries containing certain characters may cause errors
  • [FIX] - Maven goal executions cannot be properly focused on the Performance/Build cache page
  • [FIX] - Very long log lines and exception messages cause the browser to be unresponsive
  • [FIX] - Pages may be incompletely styled when browser network connection is very slow
  • [FIX] - Sign out redirects to unexpected location
  • [FIX] - Testing invalid SMTP configuration in administration produces confusing feedback
  • [FIX] - SAML IdP configuration does not allow metadata extensions
  • [FIX] - Long running database index health checks should not be considered unhealthy database queries
  • [FIX] - Support bundle should reliably indicate application configuration change history
  • [FIX] - Database diagnostics may not be captured in support bundle under heavy load
  • [FIX] - Database migration should wait for database recovery after a restore
  • [FIX] - External identity management configuration may be incorrectly displayed until system restart
Mar 15, 2021
  • [NEW] - More efficient test distribution agent utilization
  • [NEW] - Maven dependency resolution performance insights
  • [NEW] - Select build scans by start time with minute granularity
  • [NEW] - Identify Gradle 7 optimization-disabled tasks
  • [NEW] - Access the build data Export API via access key
  • [NEW] - Increased password complexity requirements for local user accounts
  • [NEW] - Tests dashboard is more responsive when analyzing many tests
  • [NEW] - Restrict allowed LDAP accounts by user filter
  • [FIX] - Date and time values are presented in the viewer’s time zone in the administration section
  • [FIX] - Performance dashboard shows most recent build scans first