Attention Gradle and Maven Build Tool Users: The next DevProd Engineering workshop is on November 10. Register now to learn how to improve dramatically the speed and reliability of your Gradle or Maven builds.
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.
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