Writing tests is hard. Fixing them is harder. Join the webinar.
Gradle Enterprise 2021.3
Gradle Enterprise 2021.3 helps you identify your slowest tests within and across builds, facilitating more effective investment in making your tests faster in order to reduce build time.
New operational capabilities such as support for horizontal scaling when deployed to Kubernetes and support for user-managed databases such as Amazon RDS allow installations to provide increased availability and performance, while also being easier to administer.
Read on for more details of these and other new features.
Use version 1.11.1 of the Gradle Enterprise Maven extension, version 3.7.2 of the Gradle Enterprise Gradle plugin, version 2.2.3 of the Gradle Enterprise Test Distribution Gradle plugin, version 1.6.14 of the Gradle Enterprise Test Distribution Agent, and version 10.3 of the Gradle Enterprise Build Cache Node for optimal usage of Gradle Enterprise.
Highlights
Identify and analyze your slowest tests
Build scans now provide a “Slowest tests” view, for both Gradle and Maven builds, making it easy to identify the longest running tests within a build.
The list of tests shown on the build scan’s “Slowest tests” view can be filtered to identify the slowest tests within a subset of the build such as those of a particular test task or goal, which is particularly useful for larger builds where different teams are responsible for different sets of tests.
While build scans make identifying the slowest tests of a single build easy, the Tests Dashboard makes identifying the slowest tests across builds easy. After using the build search criteria to identify builds to analyze, and optionally providing a test class name filter, sorting the results list by “Mean execution time” will identify the slowest tests.
Regularly investing in making your slowest tests faster is an effective way to reduce build times, in addition to other acceleration techniques such as build caching and test distribution. Gradle Enterprise makes it easy to identify the tests worth making faster, and observe reduced execution times.
More informative test outcome trend visualizations
Visualization of a test or test class’s historical outcome trend has been improved in Gradle Enterprise 2021.3, for both Gradle and Maven.
The outcome trend is now visualized as a stacked bar chart, with flaky and failed outcomes indicated above the x-axis, and successful and skipped outcomes indicated below the x-axis, with independent scales.
A thumbnail of the same visualization is also now provided for each test or test class in a search results listing. Not only is this useful for quickly identifying tests with new or already-fixed problems, but also for visualizing correlated tests — tests with identical failure patterns are likely to have a common cause.
Omit build or test logging from build scans
You can now choose to omit build and/or test logging from both Gradle and Maven build scans. While both build and test logging are immensely useful as part of build scans for debugging and troubleshooting, in some environments the risk of accidentally leaking sensitive information via this logging may be unacceptable.
Please consult the Gradle Enterprise Gradle plugin or the Gradle Enterprise Maven extension documentation for information on how to omit such logging from your build scans.
Increase build cache effectiveness across operating systems
The Gradle Enterprise Maven Extension now supports ignoring text file line endings when fingerprinting cacheable goal inputs, increasing build cache effectiveness when different operating systems are in use that use different line endings, such as when CI builds occur on Linux and developers use Microsoft Windows. This mirrors similar functionality introduced in Gradle 7.2.
Ignoring of line endings is enabled automatically for all compile and testCompile goals. It can also be enabled for custom goals using the new ignoreLineEndings option.
More accurate attribution of dependency resolution overhead
The dependency resolution tab for Gradle build scans now distinguishes between dependency resolution that occurs during configuration that was initiated by user code and that which was initiated by Gradle.
Gradle may initiate dependency resolution during configuration when composite builds or other forms of dependency substitution are in use. User-initiated configuration time dependency resolution is almost always a build logic error and should be avoided or minimized.
Easier horizontal scaling of Gradle Enterprise
When deployed to Kubernetes, Gradle Enterprise can now be easily scaled horizontally to provide greater performance and availability.
As part of the installation wizard that helps generate your deployment manifest, you can now enable horizontal scaling and specify how many application replicas should be deployed. Note that deploying more replicas requires more compute and memory resources, along with a slight increase in storage requirements.
Horizontal scaling is not applied to the embedded database that is part of Gradle Enterprise. However, a highly available user-managed database can be used in conjunction with a horizontally scaled Gradle Enterprise installation to provide even greater scalability.
Improved availability and performance with a user-managed database
Gradle Enterprise now formally supports installations with a user-managed Postgres database, as an alternative to the default embedded database. Leveraging feature-rich Postgres offerings such as Amazon RDS or Amazon Aurora can make installation administration more convenient, provide greater availability, increase application performance, and simplify backup management.
This option is available for both single-host appliance installations, and Kubernetes based installations.
When using a user-managed database, some Gradle Enterprise administrative features such as automated backups and build scan disk space management features that respond to low disk space scenarios are not available. Additionally, some installation local disk storage is still required for log files and build cache artifacts.
Existing installations using an embedded database can be transitioned to a user-managed database. A migration guide will be published shortly with more information.
Proactive build cache free disk space management
Build cache nodes can now avoid out-of-disk-space scenarios by automatically reducing their size in order to maintain a specified “free space buffer” on the disk volume they are using. By default the free space buffer size is set to 1 GiB, which is applied to both new and existing build cache nodes upon upgrade.
When a build cache node’s cache size has been reduced from the requested target size in order to maintain sufficient free space, a health monitoring warning will be issued.
Enforce a maximum age for build cache entries
Build cache nodes can now be configured with a maximum entry age, causing too-old entries to be removed from the cache regardless of when they were last accessed.
Upgrade notes
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.
Kubernetes workload resources change
In 2021.3 some Kubernetes resources have changed from prior releases.
The standard ./installer/scripts/install.sh
script will delete the stale resources when upgrading. If your deployment mechanism doesn’t use that install script, you will need to manually delete the following resources:
- statefulset/gradle-admin
- service/gradle-admin
- pvc/gradle-admin-logs-volume
- networkpolicy/gradle-admin-server-network-policy
- statefulset/gradle-server
- service/gradle-server
- networkpolicy/gradle-scans-server-network-policy
- deploy/gradle-build-cache
- service/gradle-build-cache
- pvc/gradle-build-cache-logs-volume
- networkpolicy/gradle-build-cache-server-network-policy
Changes
- [FIX] Update Alpine Docker base image to mitigate vulnerability for possible code execution
- [FIX] Database containers use disabled system call on older Docker versions
- [FIX] Update Netty to mitigate vulnerability for "Inconsistent Interpretation of HTTP Requests"
- [FIX] - Upgrade Log4j to 2.16.0 (see https://security.gradle.com/advisory/2021-11)
- [FIX] - Mitigate log4j2 RCE vulnerability (see https://security.gradle.com/advisory/2021-11)
- [FIX] - URLs with metacharacter in multi-valued query params may not display correctly
- [FIX] - Interacting with test search critieria with many auto-complete values is slow
- [FIX] - Upgrade to 2021.3 may fail in environments with a large amount of free disk space
- [FIX] - Default user-managed database name is always used
- [FIX] - Timeline order dropdown arrow is not actionable
- [FIX] - Values in build comparison view are truncated when expanded
- [FIX] - Logging of retry operations shows retry number incorrectly
- [FIX] - Tests view in build scan does not allow searching by part of test name
- [FIX] - "View task in console" link does not work when task name contains URL metacharacters
- [FIX] - Very early test executor failures are not shown in build scans
- [FIX] - Database migration data copier attempts to copy builds deleted after it has started
- [FIX] - Pre 2021.3 links to test results in build scans no longer work
- [FIX] - Build cache node details page does not display health status
- [FIX] - Build cache tab in Gradle build scans is hidden when build cache is not used
- [FIX] - Build timeline visualization "reset zoom" button does not reset all state
- [FIX] - Replicated is upgraded to 2.53.1
- [FIX] - Built-in build cache node does not work in some network configurations
- [FIX] - Built in cache anonymous access migration fails for some setups
- [FIX] - Disk usage is not monitored correctly
- [FIX] - Skipped test executions are incorrectly included in outcome distribution
- [NEW] - Horizontally scale Gradle Enterprise applications on Kubernetes
- [NEW] - Connect Gradle Enterprise to a user-managed database
- [NEW] - Build cache proactively maintains free disk space
- [NEW] - Build cache can impose maximum entry age
- [NEW] - Local build cache location is normalized
- [NEW] - Easier identification of slowest tests
- [NEW] - Improved test outcome trend visualizations
- [NEW] - Build and test logging can be omitted from build scans
- [NEW] - User-initiated configuration-time dependency resolution indicated in build scans
- [NEW] - Tests Dashboard performance is improved, particularly for builds with many tests
- [NEW] - Allow custom Maven extensions to more reliably configure the Gradle Enterprise Maven extension
- [NEW] - Ignore differences in line endings in cacheable goal inputs for Maven builds
- [FIX] - Gradle dependency selection reasons may not be properly displayed
- [FIX] - Console log cannot be filtered when the overall limit of lines is reached
- [FIX] - Timeline view is slow to load on Safari
- [FIX] - Multiple custom values with the same name and different values are not properly displayed when collapsed as part of a build comparison
- [FIX] - Long-running dashboard searches may produce unexpected error pages
- [FIX] - Changes to default user roles are not applied to existing users
- [FIX] - Weekly maintenance job can interfere with high traffic periods
- [FIX] - Build cache node default configuration is insecure, allowing anonymous writing and configuration changes