In Gradle Enterprise before 2018.5.2, Build Cache Nodes would reflect the configured password back when viewing the HTML page source of the settings page.

**Gradle Enterprise 2018.5**

Gradle Enterprise 2018.5 provides a powerful new tool for debugging build cache misses: identifying the changed input files that led to a cache miss. This makes it easier than ever before to reduce build times by optimizing your build cache usage.

New access control features allow individual user logins and role based access. Users and roles can be created and managed within Gradle Enterprise or sourced from an existing LDAP service or SAML 2.0 identity provider, allowing users to log in with their existing organization credentials.

Read on for the details of these and other new features and improvements.

Use version 2.1 of the build scan plugin for optimal usage of Gradle Enterprise.

**Highlights**

**Identify changed files causing build cache misses**

Previously, the task inputs comparison determined and visualized which _properties_ of a task changed between two builds. Now, it also determines and visualizes which _individual input files_ of a task changed between builds, making debugging unexpected build cache misses significantly easier.

This is especially helpful for tracking down build cache misses caused by timestamps or other always-changing values being written to files during the build.

A new tutorial is available explaining how to use this powerful new functionality.

This feature requires enabling capture of extra data by the build scan plugin, which results in Gradle Enterprise using more disk space to store build scans. It is strongly recommended to read the upgrade notes related to this feature for guidance on how enable it.

Task input files comparison requires Gradle 5.0+ and build scan plugin 2.1+.

**Log in with your organization credentials**

Gradle Enterprise now supports individual user login and access control. User accounts and permissions can be created and managed locally in Gradle Enterprise, or can be sourced from an LDAP service, including Active Directory, or a SAML 2.0 identity provider.

For information on configuring the new access control capabilities, please see the Gradle Enterprise Admin Manual.

With the addition of much more powerful access control, the previous shared username and password access controls have been removed. If you were using this, ensure you read the upgrade notes related to this feature for how to replace that functionality.

**Assess impact of inputs snapshotting on build time**

The task inspector in the timeline view now indicates how much time was spent “snapshotting” inputs as part of the task execution.

The term “snapshotting” refers to Gradle’s inspection of the task’s inputs in order to determine whether the task is UP-TO-DATE or whether its outputs can be retrieved from a build cache instead of executing it.

In some pathological cases, this can take a non-negligible amount of time. This can occur when there are _many_ input files to a task or when disk access is particularly slow. This is usually noticed as a task that is UP-TO-DATE is taking a surprising amount of time. The indication of how much time was spent performing snapshotting now makes it possible to understand whether this was the cause of a slow task.

Inputs snapshotting build time requires Gradle 5.0+ and build scan plugin 2.1+.

**Reduced disk space usage and improved scan viewing performance**

This release contains internal restructuring that allows more effectively freeing the space that was used by build scans that have been deleted, which reduces overall disk usage. This change also improves the efficiency of build scan viewing.

The restructuring happens in the background during the normal operation of Gradle Enterprise after upgrading. It is strongly recommended to read the upgrade notes related to this change for information on the short term increased disk usage requirements.

**Upgrade notes**

If upgrading from a version of Gradle Enterprise prior to 2018.4, be sure to also consult the release notes for all interim versions.

**Breaking changes to access control**

The new individualized access control completely replaces the previous single shared credentials based access control. If you were using the previous access control mechanism, extra configuration is needed after upgrading.

You can emulate the previous behavior by creating a single account with the previously used shared credentials. Alternatively, you may wish to use this opportunity to create multiple user accounts or connect to an existing LDAP service or SAML 2.0 identity provider.

Please see the Gradle Enterprise Admin Manual for guidance on configuring access control.

**Disk space required for database restructure**

This release includes a significant database restructure, in order to provide the reduced disk usage and performance improvements mentioned in the highlights. Migrating to the new structure happens transparently and does not require additional downtime.

While Gradle Enterprise is migrating to the new structure it requires extra disk space. In some cases it may require nearly as much free space as is currently in use. If there is not sufficient free space to perform the migration, the migration _will not be attempted_. Instead, in the footer of the application you will see a graphic that looks like the following:

After starting Gradle Enterprise 2018.5, please check the footer of the application. If you do see the graphic above, please get in contact with Gradle Enterprise technical support to resolve the issue.

The background migration may take several hours. For installations with millions of build scans, it may take a day or two. There should be no noticeable performance degradation while the migration occurs.

**Impact of enabling capture of task input files**

The new ability to identify individual files that have changed with task inputs comparison requires _opting in_ to capture of task input files with the build scan plugin. When this capture is enabled, the build scan information sent to the server includes the path to and a hash of each file used during the build. The extra information must be stored in Gradle Enterprise, increasing its disk usage.

It is recommended to enable capture of task input files for all builds and to monitor server disk usage for a week after enabling to ensure that your Gradle Enterprise installation has adequate storage capacity for this extra data.

**Build scan plugin 2.x requires Gradle 5.0 or later**

The minimum supported Gradle version for the 2.x line of the build scan plugin has been raised from Gradle 2.0 to Gradle 5.0. This has allowed significant optimizations and simplifications within the build scan plugin that will facilitate faster development of future build scan features.

Previously, it was recommended to upgrade to the latest build scan plugin when upgrading Gradle Enterprise. However, if you have not yet upgraded to Gradle 5.0 you cannot upgrade to build scan plugin 2.x until you do. Instead, you should continue to use build scan plugin 1.16 which is compatible with Gradle Enterprise 2018.5.

If you have not yet upgraded to Gradle 5.0, please consider doing so in order to get the most out of Gradle Enterprise.

**Changes**

*   \[FIX\] Retried redundant scan uploads due to network failures may cause ingestion failures
*   \[FIX\] Failed remote store build cache requests are not prominently displayed as errors
*   \[FIX\] LDAP groups used for role membership cannot use member attribute other than 'member'
*   \[FIX\] Build cache credentials are stored unencrypted at rest
*   \[FIX\] Build cache node displays empty page on error

*   \[FIX\] Daily maintenance may only partially complete for new installations
*   \[FIX\] Disk space may be only partially reclaimed when many builds are processed in a day
*   \[FIX\] Memory usage may spike during daily maintenance
*   \[FIX\] Build cache credentials are reflected in node settings page

*   \[FIX\] Cannot provide SAML metadata when metadata URL requires authentication
*   \[FIX\] Cannot search for users in admin section by other fields such as first name
*   \[FIX\] Very large build caches may require increased heap size
*   \[FIX\] Temporary database failures may cause build cache process to run out of memory
*   \[FIX\] Backup process requires much more free disk space than the backup archive size

*   \[FEATURE\] Identify changed input files with task inputs comparison
*   \[FEATURE\] Individual user accounts and access control
*   \[FEATURE\] Source user information from an LDAP service
*   \[FEATURE\] Source user information from a SAML 2.0 identity provider
*   \[FEATURE\] Assess impact of inputs snapshotting on build time
*   \[FIX\] Disk space reclaimed by deleting old build scans is not returned to the operating system
*   \[FIX\] Ingesting many large build scans may consume excess disk usage
*   \[FIX\] Build deprecated usage details are not shown if no owning plugin is known
*   \[FIX\] Top left logo does not consistently link to Gradle Enterprise home page
*   \[FIX\] Build cache key is sometimes displayed in upper case

CVE-2019-11403: 2018.5

In Gradle Enterprise before 2018.5.3, Build Cache Nodes did not store the credentials at rest in an encrypted format.

CVE-2019-11402: 2018.5

Gradle versions from 1.4 to 5.3.1 use an insecure HTTP URL to download dependencies when the built-in JavaScript or CoffeeScript Gradle plugins are used. Dependency artifacts could have been maliciously compromised by a MITM attack against the ajax.googleapis.com web site.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tag

#gradle