Next Event: DevProdEng Showdown! S1E6: Android Builds and Tests at Scale on August 19 (10:00 – 10:30 AM PT). Learn more and register here.
Gradle Enterprise 2017.6
2017.6 features internal improvements to drastically reduce the amount of disk space needed to store build scan data, allowing you to retain more build data. It also adds finer grained build cache access control and better build cache insights in build scans. Last but not least, the build scan user interface has been overhauled with new styling and usability improvements.
Read on for the details of the new features and improvements.
Use version 1.10 of the build scan plugin with this version of Gradle Enterprise for optimal build scans.
The internal mechanisms used to store build data have been optimized, reducing the amount of space required and improving performance. The exact nature of the savings are dependent on the size and frequency of your builds. Installations with larger builds will reclaim the most space. The storage requirements of our own Gradle Enterprise installation dropped from 1.4 terabytes to 400 gigabytes when upgrading to 2017.6.
Upon upgrade, existing build scans will be migrated to the new compressed format in the background over time. For larger installations this may take one to two days. Most installations will migrate completely within a few hours. During the migration, the system will remain fully functional and all new and existing data will be available. Gradle Enterprise can safely be stopped or restarted during the migration.
Disk space savings are only realized once the migration has fully completed. Furthermore, during the migration, you may see an increase in disk usage as the data is copied to the new format. Once the migration is complete, the previously used disk space will be reclaimed by your operating system.
The Gradle Enterprise Admin Console charts the disk usage of your installation over time. The following is a snapshot of this chart after upgrading a test installation to Gradle Enterprise 2017.6.
Previously, you could allow read-write anonymous access to your build caches, or specify one or two sets of username/password credentials required for read-write access. Now, an arbitrary number of username/password credentials can be be allowed for each cache with designated read-only or read-write access. Anonymous access may be configured independently to be disabled, read-only or read-write.
This makes it easier to implement an emerging pattern in build cache usage where write access is restricted, while allowing anonymous read access in order to avoid the need to provision build cache credentials for every day build users.
Use of finer grained access controls with remote cache nodes requires upgrading the node to version 2.0. Existing version 1.x remote nodes are still supported by Gradle Enterprise 2017.6.
The build cache information shown on the task details view has been further improved, showing the build cache outcome more prominently, and more clearly listing the individual interactions with the local and remote cache.
The “Build cache” tab in the “Performance” section now aggregates and details all of the interactions with the local cache for the build, in a similar manner to the existing remote cache section.
The JVM’s default character set is used to convert binary data to text (e.g. reading a text file) whenever an explicit character set is not provided. This commonly occurs in many builds, in custom build logic and plugins.
Differences in the JVM’s default character set may result in different build results. Build scans now indicate the default character set used for the build, and highlight differences during build scan comparison.
Most modern operating environments default the default character set to UTF-8. If your projects are built in different environments, consider explicitly setting the default character set for your builds by adding
org.gradle.jvmargs=-Dfile.encoding=UTF-8 to a
gradle.properties file at the root of your project.
Build scan data compaction
As detailed above, Gradle Enterprise 2017.6 includes a significant data migration to a more compact build data format. This migration occurs during normal operation of Gradle Enterprise and does not require a significant downtime. Upon first restart after upgrading, you may notice a delay of a few minutes before Gradle Enterprise becomes fully functional while it prepares for this migration.
The data migration requires extra disk space while in progress. Please ensure that you have at least 10% of the disk volume allocated to Gradle Enterprise free before upgrading. Once the migration has completed, you will see a significant reduction in the space used on this volume.
Build cache artifact database restructuring
An internal change to the build cache requires restructuring the build cache artifacts on disk. This may be noticeable as a delay of a few minutes upon restarting Gradle Enterprise upon upgrade if you have a significantly large cache of artifacts for the built-in build cache node. A 50 gigabyte artifact cache on an SSD-class disk drive will be updated in less than one minute.
- [ENHANCEMENT] Build scans ingest throughput is improved
- [FIX] UP-TO-DATE tasks that executed before deciding they were up to date may show “not up to date messages”
- [FIX] UP-TO-DATE tasks may incorrectly show a “local miss” build cache operation
- [FIX] Tags are shown in lower case in scan list
- [FIX] System may regularly use excessive CPU due to status checking queries
- [FIX] Build cache store schema update in 2017.6 may prevent startup if cache contains 500,000 artifacts or more
- [FIX] Gradle Enterprise may start slowly if build cache contains 1 million artifacts or more
- [FEATURE] Store build data more efficiently, reducing disk space usage
- [FEATURE] Provide finer grained access to the Gradle Enterprise build cache
- [FEATURE] Specify build cache remote node settings from the node itself
- [FEATURE] Display local build cache interactions
- [FEATURE] Display the build JVM's default character set
- [FIX] Dependency comparison for very large dependency graphs may be very slow
- [FIX] Task inputs comparison is not available when the build cache is disabled
- [FIX] Task inputs comparison displays a difference indicator when data won't be displayed
- [FIX] Build run with a single use daemon is incorrectly presented as run with the daemon
- [FIX] Performance of the data cleanup script may be very slow
- [FIX] Warning about slow disk is not displayed during installation
- [FIX] Warning about using a too new Docker version is incorrectly displayed during installation
- [FIX] Support bundle does not contain heap dump data