This year’s Gradle Summit was recently held and if you weren’t there, you missed out on some pretty exceptional talks. The videos will be posted in the future to Gradle’s YouTube channel, so you’ll be able to catch up.

One of the most interesting announcements during the keynote was that Gradle has continued it’s push into expanding past being a build tool that is run on a local machine. Their first foray into SaaS type services came at last year’s Gradle Summit with the introduction of Build Receipts. In the last year, this beta feature has been completely revamped and relaunched as Build Scans on the new gradle.com

What is a Build Scan?

A Gradle Build Scan is a collection of meta-data about a build executed by the Gradle Build Tool. This meta-data packaged is uploaded to the Gradle.com servers and then provided to users. The meta-data payload contains a variety of information about a build at at this time (with more information to come):

• Executed Tasks with timings
• Console output
• Detailed performance details
• Test reports
• Dependency information
• Build plugin information
• Gradle runtime switches & options
• System Information (CPU, Memory, JRE, etc)

Build Scans are free to generate, upload, and view from Gradle.com. However, if your organization is concerned about sending this type of meta-data external, the service is offered in an Enterprise configuration that can be self-hosted in your own datacenter.

Publishing Build Scans

First, install the build-scan plugin into your build (detailed steps can be found here)

plugins {
    id 'com.gradle.build-scan' version '1.0'
}

Once the plugin is installed, you will need to accept the Terms of Service for sending the build data to Gradle’s cloud service.

buildScan {
    licenseAgreementUrl = 'https://gradle.com/terms-of-service'
    licenseAgree = 'yes'
}

If you using build scans on an open source software project, you should wrap the above license acceptance in a configuration block such that it only executes on system’s that the project controls or explicitly requires a user to configure their own acceptance.

Once the plugin is installed, you can publish a build scan by passing the -Dscan option to any Gradle command:

$ gradle build -Dscan
... 
BUILD SUCCESSFUL
 
Total time: 1 mins 6.759 secs
 
Publishing build information...
https://gradle.com/s/vessdqevqx3zq

At the end of the build, a URL for the build scan will be written to the console.

Viewing a Build Scan

At this time, Gradle.com does not have any User Accounts. This feature is being worked on and will be available in the future. For now, this means, that build scans published to Gradle.com are publicly viewable. This includes console output, so make sure you aren’t writing out any sensitive values to the console during your build. This also means that each build scan needs to be Activated before it can be viewed.

The first time you go to a build scan URL, you will be required to activate the scan.

On the screen, enter your email address and select Go!. This will generated an email to the entered address which contains a link to the activated build scan.

If you mark the Remember Me feature on the initial page, then subsequent builds will skip the email verification step and be automatically activated with the same email address.

Once your build is activated, you are presented with the Build Scan Dashboard.

Along the left side is the navigation for your build scan. This breaks out the various pieces of information that was reported to Gradle.

Summary

This section shows high level information about your build; the project name, the requested tasks, what time it was started at, how long it took, the versions of both Gradle and the Build Scan plugin used in the build.

Selecting the See console output link will display the console output for the build.

Performance

This section provides detailed information about the performance of Gradle during the build. It provides the total execution time as well as breaking down how long was spent in both the initialization/configuration and execution phases of the build.

Selecting See performance details provides additional insights.

The Build section provides a detailed breakdown of timings for each step of the build process.

The Project Configuration section provides a detailed breakdown of timings required to configure each project in your build. In a single project build, this doesn’t provide much insight, but in a large multi-project build, this details can be extremely valuable.

The Dependency Resolution section provides timings for how much time was required to resolve each dependency configuration. This includes querying for dependency information, resolving conflicts, and downloading the dependencies. Details about the dependencies themselves can be found in the top-level Dependencies section.

The Task Execution section provides a detailed breakdown of timings for each task executed.

The Settings And Suggestions section provides some analysis of our build. This is the first example of what Gradle.com will be able to provide. By analyzing the meta-data of the build, Gradle can offer suggestions to improve your build’s performance and execute faster.

Tests

This section displays the reports generated from the Gradle Test tasks in the build. It is similar to the test reports generated locally on the machine including each test name, the time to execute, and the result. Test output is not included in the Gradle.com results.

At this time, only test reports are published as part of the build scan. Other tasks that also implement Gradle’s reporting system, are not currently included in the build scan, but there are plans to eventually include these reports as well.

Tasks

This section again displays the detailed tasks timings for each task executed by the build. It will also indicate if a task was skipped due to being UP-TO-DATE. The tasks are aggregated by the parent project in a multi-project build.

Projects

This section displays information about sub-projects in a multi-project build.

Dependencies

This section provides detailed information about your build’s dependencies. It is similar to the output of Gradle’s dependencies task. The dependencies are broken down by the configuration which resolved the dependency and displays the dependencies in a hierarchical fashion that indicates declared dependencies and dependencies that were resolved transitively.

The Gradle.com site also allows for searching the dependency graph to see how and what version a specific dependency is resolved. Select the magnifying glass icon in the top left of the dependencies details page to activate the search feature.

Plugins

This sections provides information about the Gradle plugins applied to the build. It displays the plugin ID along with the concrete class that implements that plugig, whether the plugin is provided by Gradle as a core plugin or is a 3rd party external plugin, and the plugin version.

Again a search feature is available to quickly find the details regarding a specific plugin.

Switches

This section displays information about the runtime switches that were passed to the Gradle build. It will identify which features such as parallel builds, configuration on demand, daemon mode, etc were enabled at build time.

Infrastructure

This section displays information about the machine that executed the build. It includes system information such as CPU and memory, the JVM version used to execute the build along with JVM heap memory, network information such as IP address and hostname, the operating system, and the configured locale.

Impressions

Build Scans, while young, is a substantial leap forward for the Gradle team. Even in this early iteration, it is apparent the power that Gradle.com will bring to development teams and build authors/maintainers. This will be especially apparent when a developer needs assistance in finding out why a build failed. With a simple URL, any developer can shared the information about a build, regardless of where it was executed, to others.

Gradle.com will also be a significant tool in conjunction with hosted Continuous Integrations services such as TravisCI, etc. Most of these SaaS CI offerings don’t include support for introspecting builds beyond the console output and downloading archived files. This makes tasks like, viewing test failures exceptionally difficult. Gradle.com can fill this gap by acting as the build results repository for these types of builds. It isn’t hard to imagine that as the tool matures, we will be able to view and plot historical performance of builds across a project.