Gradle Enterprise 2019.2

The new build trends dashboard visualizes the trends of key build performance and volume metrics for Gradle and Maven builds. This new visualization complements the existing performance dashboard’s per build visualization by aggregating metrics into day, week and month time intervals.

It can be used to confirm regressions or optimizations and their contributing factors. For example, analyzing the trend of “avoidance savings” (i.e. the amount of time saved by build avoidance measures such as incremental building and building caching) can indicate whether build times have regressed due to reduced effectiveness of avoidance measures.

Learn more in this blog post introducing build trends.

Gradle Enterprise 2018.2 introduced a performance dashboard for visualizing key performance metrics per Gradle build. This is now also available for Maven builds.

This view is particularly useful for identifying spikes and anomalies in behavior and can be used for analyzing trends visualized by the new build trends view mentioned above.

The performance metrics visualized for Maven builds are logically equivalent to those visualized for Gradle builds. Refer to the introduction of this feature for Gradle builds to learn more.

The new Maven goal inputs comparison function identifies causes of a build cache miss, making it faster and easier to optimize and maintain your build’s cacheability. It is the logical equivalent of the task inputs comparison function introduced in Gradle Enterprise 2018.5 for Gradle builds.

Goal executions from both builds are compared and visible if differences are found in the parts relevant to build caching. Added/removed or changed properties are visible, as well as individual input files within those properties. 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.

To view a comparison, select the builds to compare from the build scan list.

You can also select any build scan your are currently looking at for comparison by clicking the comparison button at the top of the build scan.

To fully benefit from the fine-grained granularity of the goal inputs comparison feature, extra data needs to be captured by the Gradle Enterprise Maven extension, which results in Gradle Enterprise using more disk space to store build scans. It is strongly recommended to read the upgrade notes related to goal inputs file capturing for guidance on how to fully benefit from this feature.

The Gradle Enterprise Maven extension now additionally supports caching the following plugins and goals:

• Maven Javadoc plugin
  • org.apache.maven.plugins:maven-javadoc-plugin:2.7+
• Maven Checkstyle plugin
  • org.apache.maven.plugins:maven-checkstyle-plugin:2.14+
    
• Maven JAXB2 plugin
  • org.jvnet.jaxb2.maven2:maven-jaxb2-plugin:0.12.3+
    

Please refer to the Gradle Enterprise Maven extension user manual for more details.

In order to safely avoid Maven goal execution by reusing cached results, the Gradle Enterprise Maven extension must know all of the inputs used by a goal and the outputs it produces. While the extension extracts this information automatically for all supported goal types based on the goal’s properties, it is possible to use additional undeclared inputs. For example, tests may access files via the file system directly and not via the runtime classpath. It is now possible to declare such additional inputs and outputs in the POM so that such goals can be safely cached.

The same mechanism may be used to make any goal cacheable, even ones not supported by the Maven extension out of the box. Take great care to define all of the goal’s inputs and outputs before doing so, to avoid false cache hits and downstream errors.

Furthermore, if a test or compile goal is configured with a property or flag that references a file unexpectedly, the goal will automatically be made non cacheable in order to avoid potentially incorrectly caching the result.

Consult the Gradle Enterprise Maven Extension User Manual to learn more about when and how to declare additional inputs and outputs for cacheable goals.

For Java compilation tasks of Gradle builds, the time spent by each annotation processor is now listed in the task inspector within the timeline visualization.

The total time spent by each annotation processor used in the build is also listed within the “Task Execution” tab of the “Performance” section.

Build scans are now collected for composite builds that build an included project to be used as a build plugin.

The time spent building such included plugins is itemized in the “Configuration” tab of the “Performance” section.

Build scans are now collected for each build of continuous builds.

After connecting a remote build cache node to Gradle Enterprise for artifact replication or centralized management, you can now rename it or completely delete its registration from the system.

Nodes can be renamed and deleted from the “Nodes” page within the cache admin section of Gradle Enterprise.

To delete a node, you must first disable it.

Ensuring that your installation never runs out of disk space is now easier. Gradle Enterprise now actively monitors the free disk space available and can initiate different measures at configurable thresholds to avoid filling disk space. Thresholds are specified in terms of percentage of disk space free.

Thresholds can be set for emailing warnings to the administrator email address, automatically deleting older build scans and rejecting new build scans. A typical configuration would be to send warning emails at 15% of space remaining, start deleting old build scans at 10% of space remaining and reject incoming build scans at 5% of space remaining.

Thresholds can be configured in the installation settings.

In order to receive warning emails, the installation must be configured with an SMTP server to use for sending. This can also be configured in the installation settings.

Consult the Gradle Enterprise Admin Manual for more information on managing disk space usage.