Join the next DevProdEng Lowdown live webcast on March 13 – Register here.
Gradle Enterprise 2021.2
Gradle Enterprise 2021.2 makes auto scaling Test Distribution agents much more convenient, captures and visualizes test logging output for Maven builds, identifies the task critical path for Gradle builds, and more.
Read on for more details of these and other new features.
Use version 1.10.5 of the Gradle Enterprise Maven extension, version 3.6.4 of the Gradle Enterprise Gradle plugin, version 2.1.1 of the Gradle Enterprise Test Distribution Gradle plugin, and version 1.5 of the Gradle Enterprise Test Distribution Agent for optimal usage of Gradle Enterprise.
Agents are the compute resources that execute tests when using Test Distribution. With Gradle Enterprise 2021.2, it’s now easy to auto scale agents when using an elastic compute platform based on demand for how many tests there are to run.
Agent pools can now be created, along with their scaling characteristics such as the minimum and maximum number of agents. Compute platform auto scalers can consume a simple HTTP endpoint that indicates the target number of agents for each pool, based on demand. The Test Distribution Agent Manual provides step-by-step instructions for auto scaling with Kubernetes.
Real-time and historical usage can be visualized by Gradle Enterprise administrators, including the number of utilized (i.e. actually in use), connected (i.e. available to be utilized) and desired (i.e. that could be utilized if available) agents.
For Maven builds using Gradle Enterprise Maven extension version 1.10 or later, test logging output is now captured and displayed as part of the test results, making it easier to identify differences between failed and passed test executions. Test logging often contains information that aids in diagnosing failures above and beyond the test’s failure exception.
Logging output is only captured when a test fails, or when it first succeeds after having previously failed (i.e. the test succeeded when retried).
The “Timeline” section of Maven build scans now provides a graphical representation of goal executions over time, making it easier to comprehend the effects of large projects and slow goal executions on build time.
The goal executions are listed below the graphical visualization, and can be searched and filtered as they were previously. Selecting a goal execution via the graphical visualization identifies it in the list, and goal executions can be identified in the graphical visualization when inspecting a goal execution in the list.
Gradle build scans now include a “On critical path” search criterion in the “Timeline” section. When enabled, the tasks belonging to the longest chain of dependent tasks will be shown. This criterion can be combined with other existing criteria, such as outcome or cacheability.
The critical path indicates the shortest possible build time if infinite resources were available, and all non-dependent tasks were able to be executed in parallel. Those tasks are typically good candidates for optimization, as making them faster or requiring them to be executed less often can have the most impact on the overall build time.
The Gradle Enterprise Export API provides a streaming interface for consuming the raw build event data that powers build scans. Previously, it was only available for Gradle builds via the /v1 endpoints. As of 2021.2 it can be used for both Maven and Gradle builds via the /v2 endpoints. The /v1 endpoints remain available for Gradle builds and existing applications will continue to work without changes.
Please consult the Gradle Enterprise Export API User Guide for more information on the Export API.
New version of Export API supporting multiple build tools
A new version 2 of the Export API has been introduced that is more suitable for consuming build data from different types of build tools. The previous version 1 remains available for Gradle builds and existing applications will continue to work without changes.
If you do wish to migrate to the new version, please consult the migration guide.
Kubernetes workload resources change
Kubernetes based installations that use a customized installation process may need to perform extra manual steps after upgrading to remove resources that are no longer used.
Some “Deployment” workload resources have been changed to “StatefulSet” workload resources.
./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:
- [FIX] - “Authentication required” when submitting build scans with too-old Gradle version does not indicate version is too old
- [FIX] - Using browser back button after signing-in may show error page
- [FIX] - Gradle build scans do not indicate local build cache misses
- [FIX] - Long-lived Export API connections requesting compression may timeout on idle
- [FIX] - Test distribution agent pools can be created with no JDK capabilities
- [FIX] - Test distribution agent pools that scale down to 0 may become unusable
- [FIX] - Chart labels do not align correctly when viewing in a Chinese locale
- [FIX] - Overlapping long running data analysis requests may degrade application responsiveness
- [FIX] - Build scans are not created when another Maven extension executes a goal during build initialization
- [FIX] - Stop binding unused ports for appliance when configured to not need it
- [FIX] - Error page for too-slow dashboard query does not indicate query was too slow
- [FIX] - Gradle timeline section is unavailable for some builds using shouldRunAfter task ordering
- [FIX] - Clicking tasks or goals in build scan timeline may produce inconsistent behavior
- [FIX] - Cache health monitoring page is unavailable if unrelated health check fails
- [NEW] - Test distribution agent auto-scaling
- [NEW] - Maven test output visualisation
- [NEW] - Maven graphical timeline representation
- [NEW] - Gradle task critical path inspection
- [NEW] - Export API for Maven builds