Join us on April 15th at 10 am PDT for a live webinar on the emerging discipline of Developer Productivity Engineering
Gradle Enterprise 2020.1
Gradle Enterprise 2020.1 introduces visualization of the resolved dependency graph for Maven builds. This includes showing where dependencies were substituted due to conflict resolution, specific snapshot versions used, and comparison of the resolved dependencies between two Maven builds.
The dependencies and relationships between executed tasks are now visualized in Gradle build scans, making it easier to reason about why tasks were executed and the order they were executed in.
Read on for more details of these and other new features.
Use version 1.4.1 of the Gradle Enterprise Maven extension, and version 3.2.1 of the Gradle Enterprise Gradle plugin for optimal usage of Gradle Enterprise.
Maven build scans now offer a “Dependencies” section that visualizes the resolved dependency graph used to form the classpaths for each module. It is available for every captured build, without the need to invoke a specific Maven goal.
Each direct and transitive dependency is visualized, indicating the requested and selected versions of a dependency. When declaring a dependency with a version range (e.g. “[1.5,)”) the actual version selected is shown along with the requested range. When a SNAPSHOT version is requested, the unique snapshot version selected is shown. When the requested version of a dependency cannot be satisfied due to a conflict with another dependency, the version ultimately selected is shown.
The visualization can be restricted to certain projects, scopes, dependencies matching a search term, dynamic dependencies, and dependencies where the selected version was different from the requested version.
The repositories used to resolve and obtain the dependencies are also visualized, including snapshot update policies and mirror settings.
Being able to inspect and analyze the dependency resolution results for any build, in particular understanding the actual versions selected and where substitutions occurred, makes it easier than ever to debug dependency related build problems in Maven builds.
Please note: builds with large and complex dependency graphs are currently slow to render and interact with in the browser. Builds with more than 2.5 million combined graph edges cannot currently be displayed. In subsequent releases, this restriction will be removed and the general performance for large builds improved.
In addition to visualizing the dependency graph of a particular build in Maven build scans, the Maven build comparison now includes a comparison of the resolved dependencies between two builds. It shows added or removed dependencies and changes in versions, including differences in resolved snapshot version numbers.
Each difference can be traced back to the source build scan for investigation into the cause of the difference by clicking on the version for each build.
In Gradle build scans, the relationships between tasks are now explorable when inspecting a task in the “Timeline” section. New “Predecessors” and “Successors” tabs are available in the task inspector that show an explorable tree.
Predecessors are tasks that were specifically executed before the current task. This includes any tasks declared as dependencies, but also tasks that were ordered to execute before the current task using explicit task ordering (i.e. the tasks that must-run-before or should-run-before the current task). The successors are tasks that depend on the current task or were ordered to execute after it (i.e. must-run-after or should-run-after).
Both tabs allow the complete transitive graph to be explored.
Being able to explore the dependencies and dependents of a task makes it easier to reason about why tasks were executed, and to better understand task scheduling in parallel builds.
Please note: builds with many tasks are currently slow to render and interact with in the browser. In subsequent releases, the general performance when inspecting Gradle task dependencies for large builds will be improved.
A relative time window, such as “Last 7 days”, can now be used to find builds to be displayed in the build scan list or in the dashboards. When reloading the page, or using a saved link of a previous search, the data is always up to date. Previously, the time window was always fixed and had to be explicitly updated to see the latest data.
The default search criteria now include a build start time within the last 7 days. A fixed date range can still be selected, instead of using a relative time window.
Previously, some build scan search and dashboard criteria were implicitly partial and matching on prefix. For example, searching for all builds with root project name “foo” found all builds with a root project name starting with “foo”. Now, all relevant criteria use exact matching and the “*” character can be used as a wildcard to match any number of any characters. The previous prefixing behavior can still be achieved by adding “*” to the end of the search term.
The trends dashboard visualizes mean, median, 25th-75th percentile and 5th-95th percentile for each metric visualized. This is necessary to add more context to the more prominent mean metric. In cases where the percentile distributions represent a wide range of values, variations in the mean or median over time can be hard to see due to the increased scale of the graph. It is now possible to “toggle off” any of these metrics for any chart, which can reduce the scale.
Version 3.2 of the Gradle Enterprise plugin for Gradle (called the Build Scan plugin for Gradle 5.x) captures dependency information in a more optimized data structure. This significantly reduces the amount of data needed to be transferred to and stored by Gradle Enterprise, particularly for builds using the Android Gradle plugin.
Exact savings depend on several factors. Builds with more projects will experience greater savings than smaller builds.
All Gradle users are encouraged to upgrade to the latest plugin version as soon as possible to benefit from the optimizations.
Increased upgrade downtime due to database version upgrade
This release updates the Gradle Enterprise database from Postgres 11 to Postgres 12. This requires some internal Postgres data structures to be rebuilt when starting for the first time, and will happen automatically.
On a large database, the process is expected to take 10 to 15 minutes. Please allow up to 30 minutes of downtime when updating.
- [FEATURE] - Visualize and compare resolved Maven dependencies
- [FEATURE] - Visualize Gradle task dependencies
- [FEATURE] - Search for builds using a relative time window
- [FEATURE] - Use “*” as a wildcard in build scan search criteria
- [FEATURE] - Toggle individual chart metrics in trends dashboards
- [FIX] - Maven timeline page does not allow filtering for goals without an attached phase
- [FIX] - Gradle build scan performance page indefinitely loads on server error
- 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 Enterprise Gradle Plugin User Manual
- Gradle Enterprise Maven Extension User Manual
- Build Cache Node User Manual