⚡️Join us on September 5th for a live webinar on the emerging practice of developer productivity engineering.
Gradle Enterprise 2019.3
Gradle Enterprise 2019.3 introduces build failure analysis for triaging and diagnosing unexpected build failures for Gradle and Maven builds, test results and console logs for Maven builds, improved support for the latest Gradle dependency management features, and more.
Read on for more details.
Use version 1.2 of the Gradle Enterprise Maven extension, and version 2.4 of the Gradle build scan plugin for optimal usage of Gradle Enterprise.
This release of Gradle Enterprise includes tools for identifying and investigating build failure patterns within your organization.
The top failures report shows the most frequent Gradle and Maven build failures, grouped by cause and charted over time.
Gradle Enterprise partitions source code verification failures (compiling, linking, testing, linting, and so on) from non-verification failures. This will surface problems such as build configuration or infrastructure failures that are likely to be unexpected and disruptive.
Selecting a failure initiates a search for all occurrences of that failure; along with breakdowns by day, user, build hostname, and common tags.
You can search for failures you’re interested in by their message. For example, you can search for “*https://your.artifacthost.com/*” to quickly see how often builds fail due to a repository being flaky or offline.
Learn more in this blog post introducing the failures dashboard.
The build scan summary indicates the longest running tests of the build.
The tests view lists all executed tests, slowest to fastest. The tests can also be viewed by project, or be filtered to only the failed tests.
Failed tests can be clicked to see the failure exception for the test.
Build scans now also reproduce the console logging for Maven builds. This makes it easier to share and collaboratively debug builds.
The console log can be filtered for a given goal execution, which is particularly useful for the intertwined logging of builds executed in parallel.
Maven build scans now provide easy access to build scans of earlier and later builds of the same workspace (i.e. the same project directory or checkout).
This feature is particularly useful when remotely debugging an unexpected local build failure as it allows inspecting and comparing all builds of a session of builds.
The build performance and trends dashboards now visualize how much build time was spent obtaining dependencies.
This visualization is particularly useful for identifying the build time cost of ephemeral CI builds (i.e. CI builds that do not have access to any persistent file storage for local dependency caches), poor network performance, or frequent dependency changes (e.g. snapshots). It can also be used to measure and confirm potential improvements such as use of dependency repository proxies.
The details inspector of a task within the Timeline section of the build scan now indicates how much time was spent downloading dependencies and how much time was spent doing the actual task work (e.g. compiling code). This can be used to diagnose long task execution times.
If a task is the first executed that requires a set of dependencies, they must be resolved before the task can do its work. This time is included in the overall task duration visualized in build scans, but isolated in the details inspector.
Before and after performing a task’s work (i.e. executing its actions), Gradle must perform internal work such as inspecting the task’s inputs and outputs. The discrepancy between the task action execution time and the overall task duration effectively indicates the cost of this internal work.
Over the last several releases, Gradle has gained new dependency management capabilities such as dependency variants, rich version constraints, and platforms. Build scans for Gradle builds now more thoroughly visualize these new features and have been improved with more search functionality.
It is now possible to filter the dependencies visualization by project and configuration. This makes it easier to investigate dependency graphs of large multi-project builds.
The new “Versions” tab in the dependency inspector shows the different requested dependencies that resolved to the dependency being inspected due to substitution. This makes it much easier to identify the other dependencies that caused a particular dependency to be substituted.
When a dependency selection occurs as the result of conflict resolution and/or resolution rules, the dependency inspector now shows all of the reasons that led to the selection where previously only one was shown.
Gradle supports variant-aware dependency management, where different variants of a dependency can be selected based on attributes and capabilities (e.g. debug vs. release). Build scans now indicate the variant name of a dependency when more than one variant of the same dependency are present in a given configuration. The variant name, attributes and capabilities are also visible in the details inspector.
Finally, rich dependency version constraints are now displayed in the dependency details view, more usefully showing what version constraints were requested for a particular dependency.
Gradle build scans now include a new Build dependencies section that visualizes the build logic dependencies. This section includes both buildSrc dependencies and classpaths for build scripts. This makes it easier to debug dependency version conflicts of Gradle plugins and other dependency issues.
Build dependencies can also be compared between builds.
The Gradle Enterprise Maven Extension Build Scan API now offers the same functionality as its Gradle counterpart, allowing programmatic control over build scan publishing and other aspects.
For example, you can use the BuildScanApi.publishAlwaysIf() method to publish only if a CI system property is set or based on any other criteria.
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.
- [FEATURE] Build failure analysis
- [FEATURE] Test results for Maven builds in build scans
- [FEATURE] Console logging for Maven builds in build scans
- [FEATURE] Workspace build history for Maven builds
- [FEATURE] Dependency download time visualization
- [FEATURE] More fine-grained Gradle task duration breakdown in build scans
- [FEATURE] Enhanced Gradle dependency insights
- [FEATURE] Build logic dependencies in Gradle build scans
- [FEATURE] Enhanced Gradle Enterprise Maven Extension Build Scan API
- Gradle Enterprise Getting Started Guide for Gradle users
- Gradle Enterprise Getting Started Guide for Apache Maven users
- Gradle Enterprise Administration Manual
- Gradle Enterprise Version Compatibility
- Gradle Build Scan Plugin User Manual
- Gradle Enterprise Maven Extension User Manual
- Build Cache Node User Manual