Gradle Enterprise 2017.7
New build cache replication enables faster builds, by allowing build cache nodes to be installed closer to developers. New quick navigation in build scans makes it faster to get to the section you want, by simply typing where you want to go.
Use version 1.11 of the build scan plugin with this version of Gradle Enterprise for optimal build scans.
The bandwidth and latency of the network link between a build and a build cache significantly affects build performance. New replication capabilities allow users to use a cache node that they have a better network link to, while reusing artifacts from another cache node that is further away. This is particular effective for geographically distributed teams.
If a cache node receives a request for a cache item it does not have but its replication source does, it will take a copy of it and then serve it. This initial request may not be faster than using the replication source directly, but subsequent requests by all nodes with the given replication source will be faster.
A typical arrangement is to have continuous integration builds push to a cache node on a local network, and have other nodes used by developers in different locations, ideally on their local network, use it as their replication source.
The potential performance benefits depend considerably on the specific network environment and build. Using a cache node via a local network connection is profoundly faster than via an Internet connection. Just using a cache node over the Internet that is physically closer can be a significant improvement, due to the decreased latency.
Consult the Gradle Enterprise Admin Manual for more details on installing additional remote cache nodes and configuring replication.
Press ctrl+space, or click the icon in the header, while viewing a build scan to bring up the quick navigation dialog.
Use the keyboard up and down arrows to select the section you want to see, or just start typing the name of the section and hit enter.
This “application launcher” style interface makes it much more convenient to quickly navigate and explore a build scan.
The performance section of a build scan illuminates different aspects of the build that contribute to the speed of the build, and is particularly useful when optimizing or debugging performance problems. Optimizing and debugging are often collaborative endeavors and it is helpful to share the performance information within a build scan with others.
In order to make this more efficient, it is now possible to focus on any item within this section, by clicking the icon displayed when hovering over an item.
Focussing visually highlights the item, and updates the browser's location to convey this focus. When sharing the current page URL with colleagues, they will see the same focus upon following the link and immediately see exactly what it was you wanted them to see.
Post install downtime
This release includes database migrations that may take some time to perform when restarting Gradle Enterprise for the first time after upgrading.
All large installations should plan a downtime of between 15 and 30 minutes. Moderately sized installations will require less downtime. Users making heavy use of the build cache should plan for a longer downtime, of up to 1 hour.
Upgrading remote cache nodes
This version of Gradle Enterprise adds support for version 3.0 of the remote cache node. While existing remote cache nodes will continue to function, upgrading all existing remote nodes is strongly recommended.
- [FEATURE] Deploy closer build cache nodes for faster builds
- [FEATURE] Get around build scans faster with quick keyboard navigation
- [FEATURE] Share specific build performance information
- [FIX] Scan list search controls are not styled consistently
- [FIX] Admins are not notified when an error occurs processing a build scan
- [FIX] Support bundles do not contain diagnostic info on build scans that could not be processed
- [FIX] Build cache log files may grow very quickly