Gradle Enterprise 2020.4

Gradle Enterprise 2020.4 similar build failure detection makes it easy to identify whether a build failure is unique or widespread, while improved fault tolerance for test distribution decreases the disruption of unreliable network environments, and more efficient build data storage allows retaining more build history. Configuring and administering a Gradle Enterprise installation is also now much more convenient.

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

Use version 1.7.2 of the Gradle Enterprise Maven extension, version 3.5.2 of the Gradle Enterprise Gradle plugin, version 1.2.1 of the Gradle Enterprise Test Distribution Gradle plugin, and version 1.2 of the Gradle Enterprise Test Distribution Agent for optimal usage of Gradle Enterprise 2020.4.

Highlights

Correlation and analysis of similar build failures

Build scans now indicate how many other builds failed with similar failures in the last 7 days, providing an important signal on whether a problem is unique or widespread.

Similar failures are identified by using semantic analysis of failure messages. This feature is available for Gradle and Apache Maven™ builds.

Learn more about this and other Gradle Enterprise build reliability features in this new video.

More efficient test failure analysis

The Tests dashboard identifies and highlights the most flaky or failing tests across a number of builds, making prioritization and analysis of test reliability problems more efficient than anecdotal and reactive improvement efforts. New in this release is the display of test failure messages in the test history view, making analysis of whether a test is failing in different ways much more efficient than it was previously.

This feature is available for Gradle and Apache Maven™ builds.

Learn more about Gradle Enterprise test reliability features in this new video.

Improved identification of Maven sub-module builds

Previously, when executing a Maven build from a sub-module, the displayed project name was the name of that sub-module, making it cumbersome to associate builds from different sub-modules of the same multi-module Maven build. Now, the top-level project name is used, making it much easier to find and correlate build scans of the same project in Gradle Enterprise.

This feature requires Gradle Enterprise Maven Extension 1.7+.

Reduced disruption of test distribution infrastructure faults

Prior to this release, network faults and other system failures involving test distribution infrastructure and builds were likely to cause the build to fail. Now, Gradle Enterprise will reschedule work and reallocate resources in response to failure, avoiding build failure and significant disruption. Moreover, unresponsive network connections are now detected sooner, further reducing disruption.

While Gradle Enterprise 2020.4 is backwards compatible with 1.1.x versions of the Test Distribution Gradle plugin and Test Distribution agent, in order to benefit from these improvements you need to upgrade both to the latest 1.2.x versions.

More efficient build data storage and processing

The storage engine used to persist build scan data has been significantly improved in Gradle Enterprise 2020.4 to reduce disk space usage and processing times.

The exact reduction in space and processing time is dependent on usage patterns. Most installations can expect a reduction in storage of 20-40%, and increase in processing throughput of 30-40%.

Upon upgrading, all existing data is reprocessed and stored in the improved format. It is strongly recommended to read the upgrade notes related to this change for information as this migration process temporarily increases system requirements.

More convenient administration and configuration

Administration and configuration of Gradle Enterprise is now more convenient as it can now be done within Gradle Enterprise itself. Previously, configuration was predominantly performed via a separate application for single-host installations or via application manifests for Kubernetes installations. This required separate access control and made changing configuration cumbersome for application administrators that did not have administrative access at a system level. Now, Gradle Enterprise can be configured via its web interface using its access controls.

To access the new configuration interface, select “Administration” from the menu in the top right corner of the page when accessing Gradle Enterprise in your browser.

NOTE: There are important post-upgrade steps required for some users relating to this feature. Please be sure to read the upgrade notes.

Upgrade notes

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

System user password and administrator access

If access control has not previously been explicitly enabled for your installation of Gradle Enterprise, after upgrading to 2020.4 you must change the password for the built-in system user from its default – not doing so is a considerable security risk. If you have previously enabled access control, you do not need to change the system user password.

To change the system user password, access Gradle Enterprise in your browser immediately after upgrading and use the “Sign in” button in the top right corner. Log in as user “system” with password “default”. You will be required to set a new password for the system user. More information about the system user can be found in the administration manual.

Changes to unattended installation process

The changes to how Gradle Enterprise is configured in this release are a significant step towards a much simpler and more robust unattended installation process for Gradle Enterprise. If you have an established unattended install procedure for your installation, please contact Gradle Enterprise technical support before upgrading to coordinate changing this process to be compatible with the new configuration approach.

Temporary increase in disk space requirements and reduced system performance

This release includes a significant optimisation of the build data storage and processing engine. After upgrading, all existing data will be reprocessed. This occurs in the background while the application is running, and does not prevent any usage. Reprocessing the data temporarily requires additional disk space to copy batches of data at a time.

Please ensure that your installation has at least 10% of the data volume free prior to upgrading. If there is not sufficient free space to perform the reprocessing, it will not be attempted. Instead, in the footer of the application you will see a message that looks like the following:

After starting Gradle Enterprise 2020.4, please check the footer of the application. If you do see the message above, please contact Gradle Enterprise technical support to resolve the issue.

The reprocessing may take several hours. For installations with a very large amount of data, it may take several days. Typically, additional space will only be required for an initial period as the space saved after reprocessing initial batches will be greater than the space required to reprocess the remaining batches of data.

The reprocessing may also temporarily degrade overall system performance due to the increased workload. It is strongly recommended to initiate the upgrade process at the start of a quiet period to minimize the impact on Gradle Enterprise users.

Updating Gradle plugin and Maven extension version

The storage and processing optimizations previously mentioned also apply to build scan data as it is sent from builds to the Gradle Enterprise server. Version 3.5 of the Gradle Enterprise plugin for Gradle and version 1.7 of the Gradle Enterprise extension for Maven send data to Gradle Enterprise which is smaller and faster for the server to process.

It is strongly recommended that builds be updated to use these new versions shortly after upgrading the Gradle Enterprise server.

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.

Changes

2020.4.3
Nov 24, 2020
  • [FIX] - Migration script fails when there is an LDAP identity provider and roles are managed in LDAP
  • [FIX] - Gradle Enterprise Operator image is not published to docker registry for airgapped Kubernetes installations
2020.4.2
Nov 23, 2020
  • [FIX] - Application configuration parameters containing quotes may prevent system from starting
  • [FIX] - External identity provider “system” account may be used instead of local system account
  • [FIX] - User menu incorrectly indicates that user has not logged in on some pages
  • [FIX] - Pending build scan comparison selection is lost when changing views
2020.4.1
Nov 09, 2020
  • [FIX] - Test result page may list executions in incorrect order when execution duration is sub-millisecond
  • [FIX] - Test result page shows message about execution output not being captured when it is
  • [FIX] - Configuration cannot be saved when a text parameter value is a number
  • [FIX] - SMTP server connection password is incorrectly migrated from previous versions for Kubernetes installations
  • [FIX] - Additional trust certificates are incorrectly migrated from previous versions
  • [FIX] - Auto deletion of old build scans does not initiate quickly enough during data migration
  • [FIX] - Many concurrent build scan uploads causes upload token validity check to be very slow
  • [FIX] - Old build scan deletion on startup does not reliably use the most efficient deletion process variant
  • [FIX] - Logs for all initialization containers are not included in Kubernetes support bundles
  • [FIX] - Test distribution websocket connections are closed incorrectly, leading to verbose logging
2020.4
Oct 28, 2020
  • [FEATURE] - Correlation and analysis of similar build failures
  • [FEATURE] - More efficient test failure analysis
  • [FEATURE] - Improved identification of Maven sub-module builds
  • [FEATURE] - Reduced disruption of test distribution infrastructure faults
  • [FEATURE] - More efficient build data storage and processing
  • [FEATURE] - More convenient administration and configuration
  • [FEATURE] - Tags in build scan summary section link to build scans with same tag in build scans list
  • [FIX] - Incorrect project name may be displayed in tests dashboard for Gradle builds
  • [FIX] - Some dashboards may not filter by build tool versions
  • [FIX] - Maven dependencies section does not show the correct data when clearing the search fields
  • [FIX] - Focusing a repository with the same ID as another causes error in Maven dependencies repositories view
  • [FIX] - Focusing a plugin applied several times causes error in Gradle plugins view
  • [FIX] - Non-applicable filters are used when switching tabs in dependencies comparison
  • [FIX] - Long logging lines emitted by forked processes are not properly rendered in Gradle build scans
  • [FIX] - Rendering multiple exceptions sharing same causes causes an error
  • [FIX] - Chart time-valued labels are rendered more concisely and consistently across charts

View Documentation View All Releases