Gradle Enterprise 2017.6

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.