The Develocity Gradle plugin enables integration with Develocity and scans.gradle.com.

This plugin was previously named and referred to as the “build scan” plugin. With the release of Gradle 6.0 and version 3.0 of this plugin, it has been renamed to the “Gradle Enterprise” plugin. As such, when discussing older versions this document uses the term “build scan” when referring to the plugin.
In addition to Build Scans, the Develocity Gradle plugin also enables usage of Predictive Test Selection and Test Distribution.

Getting set up

Version 3.16.2 is the latest version and is compatible with all Gradle 5.x and later versions. See Gradle 4.x and earlier if you are using an earlier version of Gradle.

The instructions in this section describe applying and configuring the plugin for a single Gradle project. See Integrating your CI tool for help with integrating all projects built within an environment.

Applying the plugin

Gradle 6.x and later

This version of Gradle uses com.gradle.enterprise as the plugin ID. The plugin must be applied in the settings file of the build.

settings.gradle.kts
plugins {
    id("com.gradle.enterprise") version("3.16.2")
}

gradleEnterprise {
    // configuration
}
settings.gradle
plugins {
    id "com.gradle.enterprise" version "3.16.2"
}

gradleEnterprise {
    // configuration
}

The plugin is configured via the gradleEnterprise extension available in the settings script, which is also available via the root project in project build scripts. The same instance is used for the settings extension and root project extension.

The gradleEnterprise extension was added to the root project in version 3.2 of this plugin. Prior to that, the plugin was configured via the buildScan extension of the root project, which is now available as gradleEnterprise.buildScan.

Direct use of buildScan will be deprecated in a later release. Its usage should be replaced with gradleEnterprise.buildScan.

Gradle 5.x

This version of Gradle uses com.gradle.build-scan as the plugin ID. The plugin must be applied to the root project of the build.

build.gradle.kts
plugins {
  id("com.gradle.build-scan").version("3.16.2")
}

gradleEnterprise {
    // configuration
}
build.gradle
plugins {
  id "com.gradle.build-scan" version "3.16.2"
}

gradleEnterprise {
    // configuration
}

The plugin is configured via the gradleEnterprise extension of the root project in project build scripts.

The gradleEnterprise extension was added to the root project in version 3.2 of this plugin. Prior to that, the plugin was configured via the buildScan extension of the root project, which is now available as gradleEnterprise.buildScan.

Direct use of buildScan will be deprecated in a later release. Its usage should be replaced with gradleEnterprise.buildScan.

Connecting to Develocity

To connect to a Develocity instance, you must configure the location of the Develocity server.

Gradle 6.x and later

settings.gradle.kts
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}
settings.gradle
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}
Prior to version 3.2 of this plugin, the server address must be set via the buildScan configuration object.

Gradle 5.x

If using plugin 3.2+:

build.gradle.kts
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}
build.gradle
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}
Prior to version 3.2 of this plugin, the server address must be set via the buildScan configuration object.

Allowing untrusted SSL communication

If your Develocity server uses an SSL certificate that is not trusted by your build’s Java runtime, you will not be able to publish build scans without explicitly allowing untrusted servers.

To do this, set the allowUntrustedServer option to true:

Disabling SSL certificate checks
gradleEnterprise {
    server = "https://develocity.mycompany.com"
    allowUntrustedServer = true
}
Disabling SSL certificate checks
gradleEnterprise {
    server = "https://develocity.mycompany.com"
    allowUntrustedServer = true
}

Use of this configuration is a security risk as it makes it easier for a third party to intercept your build scan data. It should only be used as a short term workaround until the server can be configured with a trusted certificate.

Prior to version 3.2 of this plugin, this setting must be set via the buildScan configuration object.

Authenticating

(plugin 3.1+, Develocity 2019.4+)

Develocity installations may be configured to require build scan publishing to be authenticated. Additionally, installations may be configured to only allow certain users to publish build scans.

Develocity access keys should be treated with the same secrecy as passwords. They are used to authorize access to Develocity from a build.

Automated access key provisioning

The easiest way to configure a build environment to authenticate with Develocity is to use the provisionGradleEnterpriseAccessKey task.

$ ./gradlew provisionGradleEnterpriseAccessKey

When executed, it opens your web browser and asks to confirm provisioning of a new access key. You will be asked to sign in to Develocity in your browser first if you are not already signed in.

When confirmed, a new access key will be generated and stored in the enterprise/keys.properties file within the Gradle user home directory (~/.gradle by default).

Any existing access key for the same server will be replaced in the file, but will not be revoked at the server for use elsewhere. To revoke old access keys, sign in to Develocity and access “My settings” via the user menu at the top right of the page.

If your browser cannot be opened automatically at the correct page, you will be asked to manually open a link provided in the build console.

Manual access key configuration

Access keys can also be configured manually for an environment, when automated provisioning is not suitable.

Creating access keys

To create a new access key, sign in to Develocity and access “My settings” via the user menu at the top right of the page. From there, use the “Access keys” section to generate an access key.

The access key value should then be copied and configured in your build environment via file, environment variable or the settings file.

Via file

Develocity access keys are stored inside the Gradle user home directory (~/.gradle by default), at enterprise/keys.properties, in a Java properties file. The property name refers to the host name of the server, and the value is the access key.

develocity.mycompany.com=7w5kbqqjea4vonghohvuyra5bnvszop4asbqee3m3sm6dbjdudtq

The file may contain multiple entries. The first entry for a given host value will be used.

Via environment variable

The access key may also be specified via the GRADLE_ENTERPRISE_ACCESS_KEY environment variable. This is typically more suitable for CI build environments.

The environment variable value format is «server host name»=«access key».

$ export GRADLE_ENTERPRISE_ACCESS_KEY=develocity.mycompany.com=7w5kbqqjea4vonghohvuyra5bnvszop4asbqee3m3sm6dbjdudtq && \
  ./gradlew build

The server host name is specified in order to prevent the access key being transmitted to a different server than intended. In the rare case that you require access keys for multiple servers, you can specify multiple entries separated by semicolons (requires plugin 3.6+, Develocity 2021.1+).

$ export GRADLE_ENTERPRISE_ACCESS_KEY=ge1.mycompany.com=7w5kbqqjea4vonghohvuyra5bnvszop4asbqee3m3sm6dbjdudtq;ge2.mycompany.com=9y4agfiubqqjea4vonghohvuyra5bnvszop4asbqee3m3sm67w5k && \
  ./gradlew build
Via settings file

(plugin 3.7+, Develocity 2021.1+)

The accessKey option of the plugin allows the access key to be set via the settings file.

settings.gradle.kts
gradleEnterprise {
    server = "https://develocity.mycompany.com"
    accessKey = "7w5kbqqjea4vonghohvuyra5bnvszop4asbqee3m3sm6dbjdudtq"
}
settings.gradle
gradleEnterprise {
    server = "https://develocity.mycompany.com"
    accessKey = "7w5kbqqjea4vonghohvuyra5bnvszop4asbqee3m3sm6dbjdudtq"
}

An access key configured for the server this way will take precedence over an access key set via the environment variable or access key file.

Connecting to scans.gradle.com

If the location of a Develocity server is not specified, build scans will be published to scans.gradle.com. This requires agreeing the terms of service, which can be found at https://gradle.com/terms-of-service.

You can agree to the terms of service by adding the following configuration to your build.

Agreeing to the terms of service
gradleEnterprise {
    buildScan {
        termsOfServiceUrl = "https://gradle.com/terms-of-service"
        termsOfServiceAgree = "yes"
    }
}
Agreeing to the terms of service
gradleEnterprise {
    buildScan {
        termsOfServiceUrl = "https://gradle.com/terms-of-service"
        termsOfServiceAgree = "yes"
    }
}

If you do not agree to the terms of service in your build, you will be asked interactively when trying to publish a build scan to scans.gradle.com each time you try to publish.

Be careful not to commit agreement to the terms of service into a project that may be built by others.

Using Build Scans

Controlling when build scans are published

Build scans are not automatically published after applying the plugin. The following describes the options available for controlling when to publish a build scan.

For Develocity users, it is recommended that builds be configured to publish a build scan for every build. This allows Develocity to provide more insight on your organization’s builds.

Publishing on demand

You can add the --scan argument to any Gradle build to publish a build scan.

$ ./gradlew assemble --scan
If the build does not apply the plugin, Gradle will automatically apply the most recent version available at the time that version of Gradle was released.

You can also publish a build scan for the most recently run build by invoking the buildScanPublishPrevious task added by the plugin.

$ ./gradlew buildScanPublishPrevious

Since the task name is quite long, it’s worth taking advantage of Gradle’s abbreviated command line notation for tasks:

$ ./gradlew bSPP

Publishing every build

In order to publish a build scan for every build, you can use the publishAlways() directive:

Publishing a build scan for every build execution
gradleEnterprise {
    buildScan {
        publishAlways()
    }
}
Publishing a build scan for every build execution
gradleEnterprise {
    buildScan {
        publishAlways()
    }
}

Publishing based on criteria

In order to publish a build scan automatically for some builds, you can use the following directives:

Table 1. Options for automatic publishing based on criteria
Option Description

publishAlwaysIf(boolean)

Publish a build scan if the given condition is true, regardless of whether the build succeeds or fails.

publishOnFailure()

Publish a build scan only when the build fails.

publishOnFailureIf(boolean)

Publish a build scan only if the condition is true and the build fails.

For example, if you only want to publish build scans from your CI system, which is identified by having a CI environment variable, you can do the following:

Restricting build scans to CI builds
gradleEnterprise {
    buildScan {
        publishAlwaysIf(!System.getenv("CI").isNullOrEmpty())
    }
}
Restricting build scans to CI builds
gradleEnterprise {
    buildScan {
        publishAlwaysIf(System.getenv("CI"))
    }
}

You can use the other options in the same way. If you want to configure several things based on a set of criteria, you can use an if condition instead:

Encapsulating several settings based on some criteria
gradleEnterprise {
    buildScan {
        if (!System.getenv("CI").isNullOrEmpty()) {
            publishAlways()
            tag("CI")
        }
    }
}
Encapsulating several settings based on some criteria
gradleEnterprise {
    buildScan {
        if (System.getenv("CI")) {
            publishAlways()
            tag "CI"
        }
    }
}

Configuring background uploading

(plugin 3.3+, Develocity 2020.2+)

By default, build scans are uploaded in the background after the build has finished. This allows the build to finish sooner, but can be problematic in build environments (e.g. ephemeral CI agents) that terminate as soon as the build is finished, as the upload may be terminated before it completes. Background uploading should be disabled for such environments.

Prior to version 3.3 of this plugin, build scans are always uploaded before the build finishes.

Disabling programmatically

The gradleEnterprise.buildScan.uploadInBackground property can be set to false.

Disabling background uploading
gradleEnterprise {
    buildScan {
        isUploadInBackground = false
    }
}
Disabling background uploading
gradleEnterprise {
    buildScan {
        uploadInBackground = false
    }
}

It may be desirable to conditionally set the value based on the environment.

Conditionally set background uploading
gradleEnterprise {
    buildScan {
        isUploadInBackground = System.getenv("CI") == null
    }
}
Conditionally set background uploading
gradleEnterprise {
    buildScan {
        uploadInBackground = System.getenv("CI") == null
    }
}

Disabling via system property

Background uploading can be disabled by setting the scan.uploadInBackground system property to false. The system property setting always takes precedence over the programmatic setting.

The system property may be specified when invoking the build:

$ ./gradlew build -Dscan.uploadInBackground=false

Or, can be set as part of the environment with the JAVA_OPTS or GRADLE_OPTS environment variables:

$ export GRADLE_OPTS=-Dscan.uploadInBackground=false

Or, can be set in the user’s gradle.properties file (i.e. ~/.gradle/gradle.properties).

systemProp.scan.uploadInBackground=false

Configuring project identifier

(plugin 3.15+, Develocity 2023.3+)

Detailed information regarding project-level access control can be found here.

Versions before 3.15 of this plugin do not allow specifying project identifier

Setting programmatically

The gradleEnterprise.projectId property can be set to a necessary value.

Specifying project identifier
gradleEnterprise {
    projectId = "myProject"
}
Specifying project identifier
gradleEnterprise {
    projectId = "myProject"
}

Setting via system property

Project identifier can be also set using the gradle.enterprise.projectId system property. The system property setting always takes precedence over the programmatic setting.

The system property may be specified when invoking the build:

$ ./gradlew build -Dgradle.enterprise.projectId=myProject

Or, can be set as part of the environment with the JAVA_OPTS or GRADLE_OPTS environment variables:

$ export GRADLE_OPTS=-Dgradle.enterprise.projectId=myProject

Or, can be set in the user’s gradle.properties file (i.e. ~/.gradle/gradle.properties).

systemProp.gradle.enterprise.projectId=myProject

Capturing task input files

(plugin 2.1+)

Build scans capture hashes of task inputs, to enable identifying changes to inputs when comparing builds, among other features. By default, an overall hash value for each task input property is captured. This enables identifying which properties changed for a task (e.g. the source or the classpath for Java compilation), but not which individual files changed. In order to identify file changes, the paths and content hashes of each individual input file must be captured, which can be enabled.

When to enable

Capturing task input files increases the amount of data transmitted to the build scan server at the end of the build. If the network connection to the build scan server is poor, it may increase the time required to transmit. Additionally, it may also increase the data storage requirements for a build scan server.

This data is used for build comparison and Predictive Test Selection, which are only available in Develocity. If you are using scans.gradle.com, it is not recommended that you enable capture of task input files.

If you are using Develocity and utilising its Build Cache to accelerate your builds, it is strongly recommended to enable capture of task input files as identifying which files have changed between builds with build comparison is extremely effective for diagnosing unexpected Build Cache misses.

If you are using Develocity for Predictive Test Selection enabling capture of task input files is a prerequisite.

How to enable

Task input files capture can be enabled programmatically via the buildScan extension, or via a system property.

Programmatically

To enable programmatically, use the buildScan extension added by the build scan plugin.

Enabling task input files capturing
gradleEnterprise {
    buildScan {
        isCaptureTaskInputFiles = true // for plugin < 3.7

        capture {                      // for plugin >= 3.7
            isTaskInputFiles = true
        }
    }
}
Enabling task input files capturing
gradleEnterprise {
    buildScan {
        captureTaskInputFiles = true // for plugin < 3.7

        capture {                    // for plugin >= 3.7
            taskInputFiles = true
        }
    }
}
Via system property

To enable without modifying the build script, supply a scan.capture-task-input-files system property to the build. If the property is set to false, capture will be disabled, otherwise capture will be enabled. The environmental setting always takes precedence over the programmatic setting.

The system property may be specified when invoking the build:

$ ./gradlew build -Dscan.capture-task-input-files

Or, can be set as part of the environment with the JAVA_OPTS or GRADLE_OPTS environment variables:

$ export GRADLE_OPTS=-Dscan.capture-task-input-files

Or, can be set in the project’s gradle.properties file, or the user’s gradle.properties file (i.e. ~/.gradle/gradle.properties).

systemProp.scan.capture-task-input-files

See the Build Environment chapter of the Gradle User Manual for more information on specifying system properties.

Capturing build and test outputs

(plugin 3.7+)

By default, outputs generated during the build are captured and displayed in build scans.

Note that when disabling test output capturing, test failures will still be captured.

When to disable

You may want to skip capturing build or test outputs for security/privacy reasons (i.e., some outputs may leak sensitive data), or performance/storage reasons (i.e., some tasks/tests may produce a lot of outputs that are irrelevant for your usage of build scans).

How to disable

Output capture can be disabled programmatically via the buildScan extension, or via a system property.

Programmatically

To disable programmatically, use the buildScan extension added by the build scan plugin.

Disabling build or test output logging
gradleEnterprise {
    buildScan {
        capture {
            isBuildLogging = false
            isTestLogging = false
        }
    }
}
Disabling build or test output logging
gradleEnterprise {
    buildScan {
        capture {
            buildLogging = false
            testLogging = false
        }
    }
}
Via system property

To disable without modifying the build script, supply the scan.capture-build-logging and/or scan.capture-test-logging system properties to the build. If the property is set to false, capture will be disabled, otherwise capture will be enabled. The environmental setting always takes precedence over the programmatic setting.

The system property may be specified when invoking the build:

$ ./gradlew build -Dscan.capture-build-logging=false -Dscan.capture-test-logging=false

Or, can be set as part of the environment with the JAVA_OPTS or GRADLE_OPTS environment variables:

$ export GRADLE_OPTS="-Dscan.capture-build-logging=false -Dscan.capture-test-logging=false"

Or, can be set in the project’s gradle.properties file, or the user’s gradle.properties file (i.e. ~/.gradle/gradle.properties).

systemProp.scan.capture-build-logging=false
systemProp.scan.capture-test-logging=false

See the Build Environment chapter of the Gradle User Manual for more information on specifying system properties.

Extending build scans

(plugin 1.1+)

You can easily include extra custom information in your build scans in the form of tags, links and values. This is a very powerful mechanism for capturing and sharing information that is important to your build and development process.

This information can be anything you like. You can tag all builds run by your continuous integration tool with a CI tag. You can capture the name of the environment that the build published to as a value. You can link to the source revision for the build in an online tool such as GitHub. The possibilities are endless.

You can see how the custom data appears in figures 1 and 2:

scan with custom data 1
Figure 1. A build scan containing tags and links
scan with custom data 2
Figure 2. A build scan containing custom values

Develocity allows listing and searching across all of the build scans in the system. You can find and filter build scans by tags and custom values, in addition to project name, outcome and other properties. In figure 3, for example, we are filtering for all build scans that have the tag "CI" and a git branch name of "master":

build scan filtered list
Figure 3. A filtered list of build scans in Develocity

Adding tags

Tags are typically used to indicate the type or class of a build, or a key characteristic. They are prominent in the user interface and quickly inform a user about the nature of a build. A build can have zero or more tags.

They can be added at build time via the tag() method:

Adding tags to a build’s build scans
gradleEnterprise {
    buildScan {
        tag(if (System.getenv("CI").isNullOrEmpty()) "Local" else "CI")
        tag(System.getProperty("os.name"))
    }
}
Adding tags to a build’s build scans
gradleEnterprise {
    buildScan {
        if (System.getenv("CI")) {
            tag "CI"
        } else {
            tag "Local"
        }

        tag System.getProperty("os.name")
    }
}

As demonstrated by the example above, tags are typically applied either as fixed strings within a condition or evaluated at runtime from the environment. But there are no set rules that you need to follow—these are only suggestions.

The syntax for adding a tag is:

tag(<tag>)

where the <tag> is a string.

Note that the order in which you declare the tags doesn’t affect the build scan view. They are displayed in alphabetical order, with any all-caps labels displayed before the rest.

Build scan plugin v1.9.1+ impose limits on captured tags:

  • maximum tag count: 50

  • maximum tag length: 200 characters

Builds rarely live in isolation. Where does the project source live? Is there online documentation for the project? Where can you find the project"s issue tracker? If these exist and have a URL, you can add them to the build scan.

They can be added at build time via the link() method:

Adding a VCS URL to a build’s build scans
gradleEnterprise {
    buildScan {
        link("VCS", "https://github.com/myorg/sample/tree/${System.getProperty("vcs.branch")}")
    }
}
Adding a VCS URL to a build’s build scans
gradleEnterprise {
    buildScan {
        link "VCS", "https://github.com/myorg/sample/tree/${System.getProperty("vcs.branch")}"
    }
}

The above example demonstrates how you can attach a link to an online VCS repository that points to a specific branch provided as a system property.

The syntax for adding a link is:

link(<label>, <URL>)

The <label> is simply a string identifier that you choose and that means something to you.

You can see the effect of a custom link in figure 1, which shows how a label Source becomes a hyperlink that anyone viewing the build scan can follow.

Build scan plugin v1.9.1+ impose limits on captured links:

  • maximum link count: 20

  • maximum link label length: 100 characters

  • maximum link url length: 100,000 characters for build scan plugin 3.7+; 1,000 characters otherwise

Adding custom values

Some information just isn’t useful without context. What does "1G" mean? You might guess that it represents 1 gigabyte, but of what? It’s only when you attach the label "Max heap size for build" that it makes sense. The same applies to git commit IDs, for example, which could be interpreted as some other checksum without a suitable label.

Custom values are designed for these cases that require context. They’re standard key-value pairs, in which the key is a string label of your choosing and the values are also strings, often evaluated from the build environment.

They can be added at build time via the value() method:

Adding custom values to a build’s build scans
gradleEnterprise {
    buildScan {
        value("Build Number", project.buildNumber)
    }
}
Adding custom values to a build’s build scans
gradleEnterprise {
    buildScan {
        value "Build Number", project.buildNumber
    }
}

The above example demonstrates how you can read the build number from a project property—assuming you have your build set up for this—and attach it to the build scans as a custom value.

The syntax for adding a value is:

value(<key>, <value>)

where both the <key> and the <value> are strings.

As with tags, you can filter build scans by custom values in Develocity.

Build scan plugin v1.9.1+ impose limits on captured custom values:

  • maximum custom value count: 1,000

  • maximum custom value key length: 1,000 characters

  • maximum custom value value length: 100,000 characters

Adding data at the end of the build

(plugin 1.2+)

The examples you have seen so far work well if when the custom data is available at the beginning of the build. But what if you want to attach data that’s only available later? For example, you might want to label a build as "built-from-clean" if the clean task was run. But you don’t know if that’s the case until the task execution graph is ready.

The build scan plugin provides a buildFinished() hook that you can use for these situations. It defers attaching custom data until the build has finished running. As an example, imagine you want to report how much disk space was taken up by the output build directory. The build doesn’t know this until it’s finished, so the solution is to calculate the disk space and attach it to a custom value in the buildFinished() hook:

Adding a custom disk usage value at the end of the build
gradleEnterprise {
    buildScan {
        buildFinished {
            value("Disk usage (output dir)", buildDir.walkTopDown().map { it.length() }.sum().toString())
        }
    }
}
Adding a custom disk usage value at the end of the build
gradleEnterprise {
    buildScan {
        buildFinished {
            value "Disk usage (output dir)", buildDir.directorySize().toString()
        }
    }
}

The buildFinished() action has access to the rest of the build, including the Project instance, so it can extract all sorts of information. It also has access to a BuildResult instance that you can use to determine whether the build failed or not, like so:

Checking build status from buildFinished()
gradleEnterprise {
    buildScan {
        buildFinished {
            if (this.failure != null) {
                value("Failed with", this.failure.message)
            }
        }
    }
}
Checking build status from buildFinished()
import com.gradle.scan.plugin.BuildResult

gradleEnterprise {
    buildScan {
        buildFinished { BuildResult result ->
            if (result.failure) {
                value "Failed with", result.failure.message
            }
        }
    }
}

The Gradle build tool has a BuildListener interface that also contains a buildFinished() hook. However, you cannot use this to attach custom data because it is triggered too late. You can use hooks like project.afterEvaluate() or the buildStarted() method of BuildListener because they are executed early enough.

Please see Using the Configuration Cache for additional considerations when the Gradle Configuration Cache is enabled.

Adding expensive data

(plugin 1.15+)

Some data that you may wish to add to your build scan can be expensive to capture. For example, capturing the Git commit ID may require executing the git command as an external process, which is expensive. To do this without slowing your build down, you can use the buildScan.background() method:

Using background() to capture an expensive custom value with Gradle 6.x+ and Configuration Cache compatibility.
import java.io.ByteArrayOutputStream
...
interface ScriptServices {
  @get:Inject val execOps: ExecOperations
}

gradleEnterprise {
  buildScan {
    val execOps = objects.newInstance<ScriptServices>().execOps
    background {
      val os = java.io.ByteArrayOutputStream()
      execOps.exec {
        commandLine("git", "rev-parse", "--verify", "HEAD")
        standardOutput = os
      }
      value("Git Commit ID", os.toString())
    }
  }
}
Using background() to capture an expensive custom value with Gradle 5.x
import java.io.ByteArrayOutputStream
...
gradleEnterprise {
    buildScan {
        background {
            val os = ByteArrayOutputStream()
            exec {
                commandLine("git", "rev-parse", "--verify", "HEAD")
                standardOutput = os
            }
            value("Git Commit ID", os.toString())
        }
    }
}
Using background() to capture an expensive custom value
gradleEnterprise {
    buildScan {
        background {
            def commitId = "git rev-parse --verify HEAD".execute().text.trim()
            value "Git Commit ID", commitId
        }
    }
}

This method takes a function that will be executed on a separate thread, which allows Gradle to continue without waiting for the expensive work to complete.

All background work will be completed before finishing the build and publishing the build scan.

Any errors that are thrown by the background action will be logged and captured in the build scan.

See the buildScan.background() API reference for more information.

Providing custom data via system properties

(plugin 1.3+)

The examples up to this point have shown how your build file or init script can pull information from the environment, via environment variables and system properties. The build scan plugin also allows you to inject any form of custom data through the use of specially named system properties. This can help you keep your build files clean of too much environment-specific information that may not be relevant to most of the users of the build.

These system properties take the following forms, depending on whether you want to inject a link, a tag or a custom value:

-Dscan.tag.<tag>
-Dscan.link.<label>=<URL>
-Dscan.value.<key>=<value>

Here are some concrete examples, which assume that the build has been configured to publish build scans automatically:

$ ./gradlew build -Dscan.tag.CI
$ ./gradlew build -Dscan.link.VCS=https://github.com/myorg/my-super-project/tree/my-new-feature
$ ./gradlew build "-Dscan.value.CIBuildType=QA_Build"

This feature is particularly useful for continuous integration builds as you can typically easily configure your CI tool to specify system properties for a build. It’s even common for CI tools to be able to inject system properties into a build that are interpolated with information from the CI system, such as build number.

$ ./gradlew build "-Dscan.value.buildNumber=$CI_BUILD_NUMBER"

Capturing the build scan ID or address

(plugin 1.9+)

The address of the build scan is included in the output at the end of the build. However, you may wish to record the ID or URL of the build scan in some other way. The build scan plugin allows you to register a callback that will receive this information. The callback is invoked after a build scan has been successfully published.

The example build script snippet below shows this feature being used to maintain a journal of created build scans.

Develocity provides the ability to search for build scans created by a certain user and/or from a particular host (along with other search criteria).

Creating a log of published build scans
import java.util.Date

gradleEnterprise {
    buildScan {
        buildScanPublished {
            file("scan-journal.log").appendText("${Date()} - ${this.buildScanId} - ${this.buildScanUri}\n")
        }
    }
}
Creating a log of published build scans
import com.gradle.scan.plugin.PublishedBuildScan

gradleEnterprise {
    buildScan {
        buildScanPublished { PublishedBuildScan scan ->
            file("scan-journal.log") << "${new Date()} - ${scan.buildScanId} - ${scan.buildScanUri}\n"
        }
    }
}

Please see the buildScan.buildScanPublished() method for API details.

Please see Using the Configuration Cache for additional considerations when the Gradle Configuration Cache is enabled.

Obfuscating identifying data

(plugin 2.4.2+)

Build scans capture certain identifying information such as the operating system username, hostname and network addresses. You may choose to obfuscate this data so that it is not decipherable in build scans when viewed, by registering obfuscation functions as part of the build scan plugin configuration.

The following examples show registering obfuscation functions for the different identifying data.

Obfuscating the username
gradleEnterprise {
    buildScan {
        obfuscation {
            username { name -> name.reversed() }
        }
    }
}
Obfuscating the username
gradleEnterprise {
    buildScan {
        obfuscation {
            username { name -> name.reverse() }
        }
    }
}
Obfuscating the hostnames
gradleEnterprise {
    buildScan {
        obfuscation {
            hostname { host -> host.toCharArray().map { character -> Character.getNumericValue(character) }.joinToString("-") }
        }
    }
}
Obfuscating the hostnames
gradleEnterprise {
    buildScan {
        obfuscation {
            hostname { host -> host.collect { character -> Character.getNumericValue(character as char) }.join("-") }
        }
    }
}
Obfuscating the IP addresses
gradleEnterprise {
    buildScan {
        obfuscation {
            ipAddresses { addresses -> addresses.map { _ -> "0.0.0.0" } }
        }
    }
}
Obfuscating the IP addresses
gradleEnterprise {
    buildScan {
        obfuscation {
            ipAddresses { addresses -> addresses.collect { address -> "0.0.0.0" } }
        }
    }
}

Please see Using the Configuration Cache for additional considerations when the Gradle Configuration Cache is enabled.

Integrating your CI tool

Jenkins

The Gradle Jenkins plugin prominently displays links to the Build Scan for any Gradle or Maven build that produce build scans, which makes it convenient to access the build scans. See the following screenshot for an example:

jenkins

Besides that, the plugin allows you to instrument all CI jobs and to publish a Build Scan without modifying the underlying projects. This eases the adoption of build scans within the company and allows configuring the Develocity Gradle plugin or Develocity Maven extension in a central place. For more information please read the documentation here.

TeamCity

The TeamCity Build Scan plugin prominently displays links to the Build Scan for any Gradle or Maven build that produce build scans, which makes it convenient to access the build scans. See the following screenshot for an example:

teamcity

Besides that, the plugin allows you to instrument all CI jobs and to publish a Build Scan without modifying the underlying projects. This eases the adoption of build scans within the company and allows configuring the Develocity Gradle plugin or Develocity Maven extension in a central place. For more information please read the documentation here.

Bamboo

The Develocity Bamboo plugin prominently displays links to the Build Scan for any Gradle or Maven build that produce build scans, which makes it convenient to access the build scans. See the following screenshot for an example:

bamboo

Besides that, the plugin allows you to instrument all CI jobs and to publish a Build Scan without modifying the underlying projects. This eases the adoption of build scans within the company and allows configuring the Develocity Gradle plugin or Develocity Maven extension in a central place. For more information please read the documentation here.

GitLab templates

The Develocity GitLab templates allow you to instrument CI jobs and to publish a Build Scan without modifying the project’s build scripts. This eases the adoption of build scans within the company and allows configuring the Develocity Gradle plugin or Develocity Maven extension at the CI level. For more information please read the documentation here.

GitHub Actions

The Gradle GitHub Action prominently displays links to the Build Scan for any Gradle build that produces build scans, which makes them convenient to access. See the following screenshot for an example:

githubactions

Besides that, the plugin allows you to instrument all CI jobs and to publish a Build Scan without modifying the underlying Gradle build, via environment variables defined in your GitHub Actions workflow. This eases the adoption of build scans within the company and allows configuring the Develocity Gradle plugin at the CI level. For more information please read the documentation here.

Using Build Caching

The Develocity Gradle plugin, since version 3.11, provides a build cache connector that can be used to leverage the build cache provided by Develocity. Gradle’s out-of-the-box support for generic HTTP build cache servers is also compatible with the build cache provided by Develocity, and can be used when the Develocity specific connector can not be used.

The Develocity specific connector should be preferred, and can be used whenever all of the following conditions are met:

  • You are using Gradle version >= 6.0

  • You are using Develocity plugin version >= 3.11

  • You are using Develocity version >= 2022.3

  • You are using Develocity Build Cache Nodes of version >= 13

Using the Develocity connector

(plugin 3.11+, Develocity 2022.3+, Gradle 6+)

Users of Gradle’s configuration cache feature must use version 7.5.1 of Gradle or later when using the Develocity build cache connector. Earlier versions of Gradle will fail with an error message stating “Could not create service of type BuildCacheController”.

The Develocity build cache connector can be used by registering the connector with Gradle and configuring it:

settings.gradle.kts
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}

buildCache {
  remote(gradleEnterprise.buildCache) {
    // configure
  }
}
settings.gradle
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}

buildCache {
  remote(gradleEnterprise.buildCache) {
    // configure
  }
}

The buildCache {} method is provided by Gradle, with the gradleEnterprise.buildCache method being provided by the Develocity plugin extension.

Without further configuration, the build will now attempt to read entries from the built-in build cache of the specified Develocity server. The connector of type GradleEnterpriseBuildCache can be configured inside the configuration block.

Credentials

If an access key has been configured for the specified Develocity server (see Authenticating), it will be used. Otherwise, requests will be sent anonymously.

Develocity also allows build caches to be configured with username and password credentials separate to access-key-based access control. To connect with a username and password credential, use the usernameAndPassword() method. The username and password will be used instead of any configured access key.

settings.gradle.kts
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}

buildCache {
  remote(gradleEnterprise.buildCache) {
    usernameAndPassword("user", "pass")
  }
}
settings.gradle
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}

buildCache {
  remote(gradleEnterprise.buildCache) {
     usernameAndPassword("user", "pass")
  }
}

Writing to the build cache

By default, Gradle will only attempt to read from the build cache. To also write to the build cache, the push property of the connector must be configured to true.

settings.gradle.kts
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}

buildCache {
  remote(gradleEnterprise.buildCache) {
    isPush = true
  }
}
settings.gradle
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}

buildCache {
  remote(gradleEnterprise.buildCache) {
    push = true
  }
}

The write attempt may be rejected due to insufficient permissions depending on the Develocity server’s access control settings.

Using Expect-Continue

(plugin 3.12+)

The Develocity Build Cache client allows opt-in use of HTTP Expect-Continue. This causes PUT requests to happen in two parts: first a check whether a body would be accepted, then transmission of the body if the server indicates it will accept it. This is particularly suitable for Build Cache servers that routinely redirect or reject PUT requests, as it avoids transmitting the cache entry just to have it rejected (e.g. the cache entry is larger than the Build Cache will allow). This additional check incurs extra latency when the server accepts the request, but reduces latency when the request is rejected or redirected.

While the Develocity Build Cache Node supports Expect-Continue, not all HTTP servers and proxies reliably do. Be sure to check that your Build Cache server does support it before enabling.

settings.gradle.kts
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}

buildCache {
  remote(gradleEnterprise.buildCache) {
    useExpectContinue = true
  }
}
settings.gradle
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}

buildCache {
  remote(gradleEnterprise.buildCache) {
     useExpectContinue = true
  }
}

Using a non-built-in cache

Develocity provides a built-in build cache, but can also leverage separately deployed build cache nodes for geographical distribution and horizontal scaling. If you are using such a non-built-in node, you must configure its address with the build cache connector.

settings.gradle.kts
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}

buildCache {
  remote(gradleEnterprise.buildCache) {
    server = "https://develocity-cache-1.mycompany.com"
  }
}
settings.gradle
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}

buildCache {
  remote(gradleEnterprise.buildCache) {
    server = "https://develocity-cache-1.mycompany.com"
  }
}

Note that the server address should be specified without any request path component.

If using access-key-based authentication, the given build cache server must be of version 13 or later and be connected with the Develocity server specified by the gradleEnterprise {} extension.

Similar to the Develocity server configuration, the remote Build Cache server configuration also provides an allowUntrustedServer option to circumvent certificate warnings:

settings.gradle.kts
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}

buildCache {
  remote(gradleEnterprise.buildCache) {
    server = "https://develocity-cache-1.mycompany.com"
    allowUntrustedServer = true
  }
}
settings.gradle
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}

buildCache {
  remote(gradleEnterprise.buildCache) {
    server = "https://develocity-cache-1.mycompany.com"
    allowUntrustedServer = true
  }
}
This is a convenient workaround during the initial evaluation, but it is a serious security issue and should not be used in production.

Using Gradle’s built-in HTTP connector

Gradle’s out-of-the-box support for generic HTTP build cache servers is also compatible with the build cache provided by Develocity, and can be used when the Develocity specific connector can not be used.

settings.gradle.kts
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}

buildCache {
  remote(HttpBuildCache::class) {
    url = uri("https://develocity.mycompany.com/cache/")
  }
}
settings.gradle
gradleEnterprise {
    server = "https://develocity.mycompany.com"
}

buildCache {
  remote(HttpBuildCache) {
    url = 'https://develocity.mycompany.com/cache/'
  }
}

When using this connector, access-key-based access control cannot be used. Instead, username and password based access control must be used which is also supported by the Develocity build cache and can be configured by administrators.

Using Predictive Test Selection

(plugin 3.11+, Develocity 2022.3+)

Develocity Predictive Test Selection allows developers to get faster feedback by running only tests that are likely to provide useful feedback on a particular code change using a probabilistic machine learning model.

For information on how to use Predictive Test Selection, please consult the Predictive Test Selection User Manual.

Using Test Distribution

(plugin 3.11+, Develocity 2022.3+)

Develocity Test Distribution takes your existing test suites and distributes them across remote agents to execute them faster.

For information on how to use Test Distribution, please consult the Test Distribution User Manual.

Using Test Retry

(plugin 3.12+, Develocity 2022.4+)

When test retry is enabled, any failed tests are retried after all the tests have been executed. The process repeats with tests that continue to fail until the maximum specified number of retries has been attempted, or there are no more failing tests.

By default, when all failed tests pass after retrying the test task will not fail. This setting can be changed so that tests that pass on retry cause the task to fail.

Tests that initially fail but pass on retry are considered “flaky” by Develocity. For information on how to detect flaky tests with test retry, please consult the Develocity Flaky Test Detection Guide.

Configuration

Retrying is not enabled by default. It can be enabled and configured via the retry extension added to each Test task by the plugin.

build.gradle.kts
import com.gradle.enterprise.gradleplugin.testretry.retry (1)

tasks.test {
    retry {
        maxRetries.set(3) (2)
        maxFailures.set(20) (3)
        failOnPassedAfterRetry.set(true)(4)
    }
}
build.gradle
tasks.named('test', Test) {
    retry {
        maxRetries = 3  (2)
        maxFailures = 20  (3)
        failOnPassedAfterRetry = true  (4)
    }
}
1 For a Kotlin-based build script, you have to include the retry DSL extension provided by the Develocity Gradle plugin.
2 The maximum number of times to retry an individual test.
3 The maximum number of test failures that are allowed before retrying is disabled for this test task.
4 Whether tests that initially fail and then pass on retry should fail the task.

Retrying only some tests

By default, all tests are eligible for retrying. The filter component of the test retry extension can be used to control which tests should be retried and which should not.

The decision to retry a test or not is based on the tests reported class name, regardless of the name of the test case or method. The annotations present or not on this class can also be used as the criteria.

build.gradle.kts
import com.gradle.enterprise.gradleplugin.testretry.retry

tasks.test {
    retry {
        maxRetries.set(3)
        filter {
            // filter by qualified class name (* matches zero or more of any character)
            includeClasses.add("*IntegrationTest")
            excludeClasses.add("*DatabaseTest")

            // filter by class level annotations
            // Note: @Inherited annotations are respected
            includeAnnotationClasses.add("*Retryable")
            excludeAnnotationClasses.add("*NonRetryable")
        }
    }
}
build.gradle
tasks.named('test', Test) {
    retry {
        maxRetries = 3
        filter {
            // filter by qualified class name (* matches zero or more of any character)
            includeClasses.add("*IntegrationTest")
            excludeClasses.add("*DatabaseTest")

            // filter by class level annotations
            // Note: @Inherited annotations are respected
            includeAnnotationClasses.add("*Retryable")
            excludeAnnotationClasses.add("*NonRetryable")
        }
    }
}

Retrying on class-level

By default, individual tests are retried. The classRetry component of the test retry extension can be used to control which test classes must be retried as a whole unit. Test classes still have to pass the configured filter.

build.gradle.kts
import com.gradle.enterprise.gradleplugin.testretry.retry

tasks.test {
    retry {
        maxRetries.set(3)
        classRetry {
            // configure by qualified class name (* matches zero or more of any character)
            includeClasses.add("*StepWiseIntegrationTest")

            // configure by class level annotations
            // Note: @Inherited annotations are respected
            includeAnnotationClasses.add("*ClassRetry")
        }
    }
}
build.gradle
tasks.named('test', Test) {
    retry {
        maxRetries.set(3)
        classRetry {
            // configure by qualified class name (* matches zero or more of any character)
            includeClasses.add("*StepWiseIntegrationTest")

            // configure by class level annotations
            // Note: @Inherited annotations are respected
            includeAnnotationClasses.add("*ClassRetry")
        }
    }
}
From version 3.12 onward, you can also use the com.gradle.enterprise.testing.annotations.ClassRetry annotation from the gradle-enterprise-testing-annotations project without any additional configuration other than the dependency.

Retrying only for CI builds

You may find that local developer builds do not benefit much from retry behaviour, particularly when those tests are invoked via your IDE. In that case we recommend enabling retry only for CI builds.

build.gradle.kts
import com.gradle.enterprise.gradleplugin.testretry.retry

val isCiServer = System.getenv().containsKey("CI")
tasks.test {
    retry {
        if (isCiServer) { (1)
            maxRetries.set(3)
            maxFailures.set(20)
            failOnPassedAfterRetry.set(true)
        }
    }
}
build.gradle
boolean isCiServer = System.getenv().containsKey("CI")
tasks.named('test', Test) {
    retry {
        if (isCiServer) {
            maxRetries = 3
            maxFailures = 20
            failOnPassedAfterRetry = true
        }
    }
}
1 Only configure retrying tests, when running on CI

Migrating from Test Retry Gradle plugin

Prior to version 3.12 of this plugin, enabling test retries required the org.gradle.test-retry plugin. It is recommended that Develocity users adopt the Develocity plugin’s retry functionality for ensured future compatibility and easier adoption of future Develocity specific features.

This plugin offers effectively the same API as the org.gradle.test-retry plugin, making migrating simple:

  • Builds using Groovy build scripts need to just remove reference to the org.gradle.test-retry plugin.

  • Builds using Kotlin DSL build scripts need to remove reference to the org.gradle.test-retry plugin and add an import of com.gradle.enterprise.gradleplugin.testretry.retry.

If you cannot easily remove the org.gradle.test-retry plugin from your build, you can disable the test retry functionality provided by the Develocity Gradle plugin by setting the system property gradle.enterprise.testretry.enabled to false.

The system property can be specified in the user’s or build’s gradle.properties file (i.e. ~/.gradle/gradle.properties).

systemProp.gradle.enterprise.testretry.enabled=false

See the Build Environment chapter of the Gradle User Manual for more information on specifying system properties.

Upgrading to Gradle 6

If you were previously using the build scan plugin 2.x with Gradle 5, upgrading to the 3.x plugin requires more than just updating the version number. The ID of the plugin has changed, and it now must be applied in the build’s settings file.

To upgrade, first locate where the 2.x plugin is being applied and remove it. This is likely to be in the root build.gradle or build.gradle.kts file, and will look similar to the following:

build.gradle.kts
plugins {
    id("com.gradle.build-scan").version("2.4.2")
}
build.gradle
plugins {
    id "com.gradle.build-scan" version "2.4.2"
}

Then, add the following to the settings.gradle or settings.gradle.kts file for the build:

settings.gradle.kts
plugins {
    id("com.gradle.enterprise") version("3.16.2")
}
settings.gradle
plugins {
    id "com.gradle.enterprise" version "3.16.2"
}

Any buildScan {} configuration should be enclosed in a gradleEnterprise {} block, or be moved to the settings file inside a gradleEnterprise {} block. Please see the Gradle 6.x section above for more information.

settings.gradle.kts
gradleEnterprise {
    server = "https://develocity.company.com"
    buildScan {
        // tags and other settings
    }
}
settings.gradle
gradleEnterprise {
    server = "https://develocity.company.com"
    buildScan {
        // tags and other settings
    }
}

Gradle 4.x and earlier

Gradle 2.1 - 4.10.2

Gradle versions earlier than 5.0 are not compatible with the latest plugin and features. plugin 1.16 is the best available version for such builds. The plugin must be applied to the root project of the build, with ID com.gradle.build-scan.

build.gradle.kts
plugins {
  id("com.gradle.build-scan") version "1.16"
}
build.gradle
plugins {
  id "com.gradle.build-scan" version "1.16"
}

Gradle 2.0

Gradle 2.0 does not support the plugins {} syntax that was introduced in Gradle 2.1. As such, the plugin must be applied differently.

build.gradle.kts
buildscript {
  repositories {
      maven(url = "https://plugins.gradle.org/m2/")
  }
  dependencies {
      classpath("com.gradle:build-scan-plugin:1.16")
  }
}
apply(plugin = "com.gradle.build-scan")
build.gradle
buildscript {
  repositories {
      maven { url "https://plugins.gradle.org/m2/" }
  }
  dependencies {
      classpath "com.gradle:build-scan-plugin:1.16"
  }
}
apply plugin: "com.gradle.build-scan"

Troubleshooting

Failed background build scan uploads

When using background build scan uploading (default behaviour since plugin version 3.3, see this section for configuration options) upload failures are not visible in the build logging due to occurring in a background process after the build has finished. Instead, errors are logged to a file located at ~/.gradle/build-scan-data/upload-failure.log. If this additional information does not help to resolve the failure, please contact technical support and include the contents of this log file.

If the background upload process fails to start, a warning is shown in the build console and uploading is performed in the build process. If this occurs, please contact technical support with the log files located at ~/.gradle/build-scan-data/<<plugin-version>>/pending-uploads/*.log.

Slow resolution of host name

Build scans attempt to determine the host name of the machine. An issue affecting macOS can cause a delay when doing this in some environments.

If you see a warning during your build that resolving the local host name is slow, you can workaround the problem by adding a host name mapping to your /etc/hosts file.

Add these lines to your /etc/hosts file, substituting your computer name for 'mbpro' in the below snippet:

/etc/hosts
127.0.0.1   localhost mbpro.local
::1         localhost mbpro.local

Late application

When using a Gradle version earlier than 4.3 or a build scan plugin version earlier than 1.10, you should declare the build scan plugin before any other plugin. This ensures that any relevant configuration data from those plugins is included in the build scans.

build.gradle.kts
plugins {
  id("com.gradle.build-scan") version "1.16" // apply before any other plugins
  id("java")
}
build.gradle
plugins {
  id "com.gradle.build-scan" version "1.16" // apply before any other plugins
  id "java"
}

Using the Configuration Cache

Many methods in the Develocity API accept arguments that are Single Abstract Method (SAM) interface types (e.g. Function or Action arguments). When using the Gradle configuration cache, passing a lambda as a SAM interface argument may cause an error since the configuration cache does not currently support caching user-provided lambdas. See this section on the Gradle documentation for further details. For languages that allow lambdas when implementing SAM interface arguments (such as Kotlin and Java) using a typed class instance will work instead.

ConventionPlugin.kt
class GradleEnterpriseConventionsPlugin : Plugin<Settings> {
    override fun apply(settings: Settings) {
        settings.apply(mapOf("plugin" to "com.gradle.enterprise"))

        settings.gradleEnterprise {
            buildScan.apply {
                // Use a typed object instead of a Lambda
                obfuscation.hostname(HostnameObfuscator())
            }
        }
    }

    class HostnameObfuscator : Function<String?, String?> {
        override fun apply(hostname: String?): String? {
            return "unset"
        }
    }
}
ConventionPlugin.groovy
class GradleEnterpriseConventionsPlugin implements Plugin<Settings> {
    @Override
    void apply(Settings settings) {
        settings.apply plugin: 'com.gradle.enterprise'

        settings.gradleEnterprise {
            buildScan {
                // This works in Groovy because a Closure is passed instead of a Lambda
                obfuscation.hostname { host -> "unset" }
            }
        }
    }
}
ConventionPlugin.java
public class GradleEnterpriseConventionsPlugin implements Plugin<Settings> {
    @Override
    public void apply(Settings settings) {
        settings.apply(Map.of("plugin", "com.gradle.enterprise"));

        GradleEnterpriseExtension extension = (GradleEnterpriseExtension) settings.getExtensions().getByName("gradleEnterprise");
        // Use a typed object instead of a Lambda
        extension.getBuildScan().getObfuscation().hostname(new HostnameObfuscator());
    }

    class HostnameObfuscator implements Function<String, String> {
        @Override
        public String apply(String s) {
            return "unset";
        }
    }
}

Appendix A: API reference

Please see the API reference for more details about programmatic configuration of the build scan plugin.

The Common Custom User Data Gradle Plugin provided by Gradle Inc. provides an example. This plugin can be applied directly to your project, or can serve as a template project for your own plugin implementation.

Appendix B: Captured information

The build scan plugin captures information while the build is running and transmits it to a server after the build has completed.

Most of the information captured can be considered to be build data. This includes the name of the projects in your build, the tasks, plugins, dependencies, names and results of tests and other things of this nature. Some more general environmental information is also captured. This includes your Java version, operating system, hardware, country, timezone and other things of this nature.

Notably, the actual source code being built and the output artifacts are not captured. However, error messages emitted by compilers or errors in tests may reveal aspects of the source code.

Listing

The list below details the notable information captured by the build scan plugin and transmitted in a build scan.

  • Environment

    • User home (system property 'user.home')

    • Username (system property 'user.name') (Can be obfuscated)

    • Local hostname (environment variable 'COMPUTERNAME' / 'HOSTNAME') (Can be obfuscated)

    • Public hostname (Can be obfuscated)

    • Local IP addresses (Can be obfuscated)

    • Build Java Virtual Machine

    • Operating System

    • Hardware

  • Build

    • Build invocation options (e.g. requested tasks, switches)

    • Build console output

    • Build failure exception messages and stacktraces

    • Build deprecation

    • Project names and structure

    • Executed tasks

    • Executed tests (using Gradle’s JVM Test task)

    • Artifact transforms

    • Applied plugins

    • Resolved dependencies

    • Network downloads (performed by Gradle)

    • Build Cache configuration

    • Background build scan publication

    • Gradle Daemon operational data (e.g. start time, build count)

    • Gradle lifecycle callbacks

    • File system watching

    • Configuration cache

    • Java toolchains

Access

Build scans published to a Develocity installation are viewable by all users that can reach the server. Develocity provides a search interface for discovering and finding individual build scans.

Build scans published to scans.gradle.com are viewable by anyone with the link assigned when publishing the build scan. Links to individual build scans are not discoverable and cannot be guessed, but may be shared.

Appendix C: Release history

3.16.2

26th January 2024
  • [FIX] Test Distribution: File transfer start/finish events are sometimes ordered incorrectly

Compatible with scans.gradle.com and Develocity 2023.4 or later.

3.16.1

14th December 2023
  • [FIX] Build Scan: Transform execution action duration is incorrectly captured

  • [FIX] Test Distribution: Executor requirements are not tracked as inputs

Compatible with scans.gradle.com and Develocity 2023.4 or later.

3.16

5th December 2023
  • [NEW] Build Scan: capture artifact transform execution data

  • [NEW] Predictive Test Selection: Selection profile can be configured via new pts.profile system property

  • [NEW] Test Distribution/Predictive Test Selection: Add support for develocity-testing-annotations version 2.0

  • [NEW] Test Distribution/Predictive Test Selection: Support for OpenTest4J file comparison failures when using Gradle 8.3+ via Tooling API clients

  • [NEW] Test Distribution/Predictive Test Selection: Fall back to regular execution if fallbackToRegularExecutionOnMissingJUnitPlatform property is set and JUnit Platform is not available

  • [FIX] Predictive Test Selection: Selection mode can not be configured via build script

  • [FIX] Test Distribution: Retry filters are not respected if tests are configured to be retried in a new JVM

  • [FIX] Test Distribution/Predictive Test Selection: JUnit’s parallel execution configuration is not respected if a single test executor is used

Compatible with scans.gradle.com and Develocity 2023.4 or later.

3.15.1

5th October 2023
  • [FIX] Test Distribution: Classpath conflict with the Develocity plugin artifact added to the test runtime classpath/module path

  • [FIX] Test retry: Fix an issue that prevented configuration cache from being used with the bundled retry plugin

Compatible with scans.gradle.com and Develocity 2023.3 or later.

3.15

13th September 2023
  • [NEW] Add support for project-level access control

  • [NEW] Add safe mode when the plugin is injected via init scripts on CI

  • [NEW] Predictive Test Selection: Add pts.enabled system property to enable / disable PTS

  • [NEW] Predictive Test Selection: pts.mode system property takes precedence over configuration in the build

  • [FIX] Plugin application fails because Test Acceleration is not compatible with Isolated Projects

  • [FIX] Build Scan: Unscheduled planned transform steps are captured as scheduled ones

Compatible with scans.gradle.com and Develocity 2023.3 or later.

3.14.1

26th July 2023
  • [NEW] Test Distribution/Predictive Test Selection: Add support for Gradle 8.3’s and JUnit 5.10’s new test dry run mode

  • [NEW] Test Retry: Retry Spock 2 parameterized methods individually rather than the entire test class

  • [FIX] Test Distribution: Finish event for test execution may have an older timestamp than the corresponding start event

  • [FIX] Test Distribution: Local test executors are reported as released after test task has finished

  • [FIX] Test Distribution: Re-scheduled tests are reported after the test executor has been released

Compatible with scans.gradle.com and Develocity 2023.2 or later.

3.14

18th July 2023
  • [NEW] Build Cache: Avoid trying to upload too-large cache entries to build cache nodes

  • [NEW] Test Distribution: Capture configuration and runtime insights in Build Scans

  • [NEW] Predictive Test Selection: Introduce mode to run remaining tests, i.e. tests that haven’t been executed for the same inputs

  • [NEW] Predictive Test Selection: Introduce selection profiles (conservative/standard/fast) to influence how many tests are selected

  • [FIX] Build Scan: Outcomes of planned transform nodes with avoided executions are not accurate

  • [FIX] Build Scan: Task is reported as created twice during configuration cache store run

  • [FIX] Predictive Test Selection: Selection requests failing due to sporadic network issues are not retried

  • [FIX] Subclasses of VerificationException are not classified as verification failures

Compatible with scans.gradle.com and Develocity 2023.2 or later.

3.13.4

19th June 2023
  • [FIX] Test Distribution: Response timeout too short when under heavy load

  • [FIX] Test Distribution/Predictive Test Selection: Test Discovery results with failures are incorrectly cached

  • [FIX] Predictive Test Selection/Test Retry: Confusing failure message when tests could not be retried

Compatible with scans.gradle.com and Develocity 2023.1 or later.

3.13.3

25th May 2023
  • [FIX] Test Retry: Update ASM to 9.5 for Java 21 compatibility

Compatible with scans.gradle.com and Develocity 2023.1 or later.

3.13.2

9th May 2023
  • [NEW] Improve reporting of plugin-caused errors to distinguish them from regular build failures

Compatible with scans.gradle.com and Develocity 2023.1 or later.

3.13.1

3rd May 2023
  • [NEW] Predictive Test Selection: Allow loading test task outputs from the Build Cache when Predictive Test Selection is enabled in Gradle 8.2 and later

  • [FIX] Build Scan: Do no emit deprecation warnings when used together with Gradle 8.2

  • [FIX] Test Distribution: Test task fails if partition-level failure is successfully retried in a new JVM

  • [FIX] Test Distribution: Upload of input files with very long names sporadically fails

  • [FIX] Predictive Test Selection: Changed must-run configuration not applied when rerunning test task

Compatible with scans.gradle.com and Develocity 2023.1 or later.

3.13

12th April 2023
  • [NEW] Build Scan: Capture planned artifact transform steps data

  • [FIX] Build Scan: javax.net.ssl.* properties are not forwarded to the background upload process

  • [FIX] Build Scan: Ineligible build cache operations are not properly filtered out when using configuration-cache

  • [FIX] Build cache connector cannot be used for settings plugin included builds

Compatible with scans.gradle.com and Develocity 2023.1 or later.

3.12.6

24th March 2023
  • [FIX] Test Distribution: classpath conflict with Apache commons-lang and commons-io

Compatible with scans.gradle.com and Develocity 2022.4 or later.

3.12.5

20th March 2023
  • [FIX] Test Retry: configuration cache incompatibility with Gradle 8.1

  • [FIX] Build Cache: incorrect server address may yield “Invalid cookie header” warning in build logs

Compatible with scans.gradle.com and Develocity 2022.4 or later.

3.12.4

2nd March 2023
  • [FIX] IDE sync builds might fail due to Kotlin script compilation capturing error

  • [FIX] Test Distribution: Build fails if remote executors are preferred but the initial request to Develocity times out

  • [FIX] Test Retry: Failed test methods are not re-executed if class-level failure occurs on retry

Compatible with scans.gradle.com and Develocity 2022.4 or later.

3.12.3

30th January 2023
  • [NEW] Test Distribution: Add support for 'filter' and 'classRetry' configuration of 'retry' extension

  • [NEW] Test Retry: Add support for JDK 19

Compatible with scans.gradle.com and Develocity 2022.4 or later.

3.12.2

4th January 2023
  • [FIX] Test Distribution: Unnecessary connection attempts to Develocity server despite Test Distribution being disabled

Compatible with scans.gradle.com and Develocity 2022.4 or later.

3.12.1

20th December 2022
  • [NEW] Do not wait for remote executors when remoteExecutionPreferred=true but no Develocity server is configured

  • [FIX] Incompatibility with Kotlin Multiplatform Test tasks

Compatible with scans.gradle.com and Develocity 2022.4 or later.

3.12

8th December 2022
  • [NEW] Add built-in support for gradle-enterprise-testing-annotations

  • [NEW] Captures skipReasonMessage when specified for the task

  • [NEW] Support to configure HTTP Expect-Continue on the Develocity build cache connector

  • [NEW] Test Retry: Test retry functionality provided by the org.gradle.test-retry Gradle plugin is integrated

  • [NEW] Predictive Test Selection: Test discovery results are cached locally

  • [FIX] Remote HTTP build cache allowUntrustedServer is ignored if gradleEnterprise.allowUntrustedServer is true

  • [FIX] Deprecation warning for undeclared usage of build service when Test Distribution or Predictive Test Selection are enabled

  • [FIX] Predictive Test Selection: Fails with a misleading "internal error" if test task input files could not be determined

Compatible with scans.gradle.com and Develocity 2022.4 or later.

3.11.4

8th November 2022
  • [FIX] Since 3.11.3, scans.gradle.com terms of service acceptance is requested regardless of whether a Build Scan is being published or not

Compatible with scans.gradle.com and Develocity 2022.3 or later.

3.11.3

31st October 2022
  • [NEW] Test Distribution: Retry file upload on content digest mismatch

  • [FIX] Plugin is not compatible with Gradle’s “stable” configuration cache feature

  • [FIX] Predictive Test Selection: Handling of multiple unique IDs per fully-qualified test class name

Compatible with scans.gradle.com and Develocity 2022.3 or later.

3.11.2

12th October 2022
  • [NEW] Test Distribution: Delete remaining files in temporary workspaces on remote agents in case of failures

  • [NEW] Test Distribution: Use gradle-enterprise-maven-extension/<version> as User-Agent for HTTP requests

  • [NEW] Test Distribution/Predictive Test Selection: Detect and fail for unsupported test engines

  • [FIX] Test Distribution: Test tasks failing with CancellationException due to concurrency issue

  • [FIX] Test Distribution: Log misleading ClassNotFoundException message on Test Distribution agents when stopping worker while session is being opened

  • [FIX] Test Distribution: Write to temporary workspaces after worker on Test Distribution agents was asked to stop

  • [FIX] Predictive Test Selection: Show misleading warning when running with --scan without having publishAlways() configured

Compatible with scans.gradle.com and Develocity 2022.3 or later.

3.11.1

10th August 2022
  • [FIX] Develocity Gradle plugin 3.11 is incompatible with Java < 11

  • [FIX] Test Distribution: Displayed total number of test classes in progress reporting does not account for executor restrictions

Compatible with scans.gradle.com and Develocity 2022.3 or later.

3.11

10th August 2022
  • [NEW] Build Scans display Java toolchain usage for tasks (requires Gradle 7.6)

  • [NEW] Develocity Test Distribution Gradle plugin has been merged into this plugin

  • [NEW] Tests can be configured as local-only or remote-only when using Test Distribution

  • [NEW] Access key authentication to Develocity build caches

  • [FIX] Prevent enabling or disabling Test Distribution or Predictive Test Selection during task execution

  • [FIX] User data capture settings are not respected on very early build failures

Compatible with scans.gradle.com and Develocity 2022.3 or later.

3.10.3

11th July 2022
  • [FIX] Improved warning message when a Build Scan can’t be published

Compatible with scans.gradle.com and Develocity 2022.2 or later.

3.10.2

9th June 2022
  • [FIX] Improve Gradle plugin ID lookups from JAR files

Compatible with scans.gradle.com and Develocity 2022.2 or later.

3.10.1

19th May 2022
  • [FIX] buildScanPublishPrevious does not capture Gradle version with which the original Build Scan was produced

  • [FIX] Events may be captured out of order under certain circumstances

Compatible with scans.gradle.com and Develocity 2022.2 or later.

3.10

19th April 2022
  • [NEW] Configuration cache store/load metrics are captured for Gradle 7.5+

  • [NEW] Build Scans are captured for builds declaring a Settings plugin using pluginManagement#includeBuild

  • [NEW] Build Scans are captured for builds declaring a Git source dependency for Gradle 6.0+

  • [FIX] Captured build cache enabled-ness may be incorrect when build’s start parameters are modified programmatically

Compatible with scans.gradle.com and Develocity 2022.2 or later.

3.9

17th March 2022
  • Capture the user home directory in order to normalize paths

  • Improve test ingestion support

Compatible with scans.gradle.com and Develocity 2022.1 or later.

3.8.1

12th January 2022
  • Improve error handling around user callbacks

  • Improve SOCKS proxy server support

Compatible with scans.gradle.com and Develocity 2021.4 or later.

3.8

20th December 2021
  • Capture directory sensitivity and line-ending sensitivity of task file inputs

  • Improve message when running build offline and trying to publish a build scan

Compatible with scans.gradle.com and Develocity 2021.4 or later.

3.7.2

18th November 2021
  • Minor performance improvements

Compatible with scans.gradle.com and Develocity 2021.3 or later.

3.7.1

20th October 2021
  • Properly capture OS name and version for macOS 11+

  • Handle early use of background for conf cache builds

Compatible with scans.gradle.com and Develocity 2021.3 or later.

3.7

15th September 2021
  • Allow configuring access key programmatically

  • Allow capturing links with up to 100000 characters

  • Allow opt-out from build and test log capturing

Compatible with scans.gradle.com and Develocity 2021.3 or later.

3.6.4

20th August 2021
  • Do not capture identical tags

  • Minor internal performance improvements

Compatible with scans.gradle.com and Develocity 2021.1 or later.

3.6.3

11th June 2021
  • Restore support for custom locales (e.g. tr-TR)

  • Make programmatically configured access key readable by Test Distribution plugin

Compatible with scans.gradle.com and Develocity 2021.1 or later.

3.6.2

1st June 2021
  • Access key can be configured programmatically

Compatible with scans.gradle.com and Develocity 2021.1 or later.

3.6.1

7th April 2021
  • Reduced memory usage for when capturing task file inputs in very large builds

Compatible with scans.gradle.com and Develocity 2021.1 or later.

3.6

15th March 2021
  • Avoid occasional build scan capture errors during IDE sync

  • The GRADLE_ENTERPRISE_ACCESS_KEY environment variable allows specifying the access keys for multiple hosts

  • Reduced memory usage for builds with lots of input files

Compatible with scans.gradle.com and Develocity 2021.1 or later.

3.5.2

4th February 2021
  • Ignore Build Cache operations related to artifact transforms (This restriction will be lifted when artifact transforms are supported in build scans)

  • Properly capture scripts or plugins applied to multiple Gradle types or multiple included builds

  • Properly capture custom links, tags and values concurrently

  • Fix deduplication of deprecated usages

Compatible with scans.gradle.com and Develocity 2020.4 or later.

3.5.1

7th January 2021
  • Improve file path normalization to properly capture file roots (e.g. workspace, Gradle user home etc.)

Compatible with scans.gradle.com and Develocity 2020.4 or later.

3.5

27th October 2020
  • Compatibility with HTTP proxies requiring content-length header for requests potentially having a body

  • More effective compression of build scan data during publishing

Compatible with scans.gradle.com and Develocity 2020.4 or later.

3.4.1

20th August 2020
  • Include diagnostics in error message when failing to load a Gradle service

  • Error in Gradle configuration capturing is fixed

Compatible with scans.gradle.com and Develocity 2020.3 or later.

3.4

23th July 2020
  • Add support for Gradle configuration cache

  • Expose Gradle Configuration Cache and File system watching start parameters

  • Expose Background build scan publication flag

  • Include third party license files and notice file

Compatible with scans.gradle.com and Develocity 2020.3 or later.

3.3.4

5th June 2020
  • Add support for basic authentication for HTTPS proxying

  • Error when using null values in proxy configuration is fixed

  • Add support for Gradle’s upcoming PlaceholderExceptionSupport in exception capturing

Compatible with scans.gradle.com and Develocity 2020.2 or later.

3.3.3

28th May 2020
  • Problems launching the background upload process are logged to the upload failure log file

Compatible with scans.gradle.com and Develocity 2020.2 or later.

3.3.2

27th May 2020
  • Stale build scan files are cleaned up

  • Dock icon is not shown on macOS when provisioning an access key

  • Problems launching the background upload process are logged to the upload failure log file

  • The Develocity Gradle Plugin jar is now digitally signed. Check the documentation’s appendix section on how to verify the signature

Compatible with scans.gradle.com and Develocity 2020.2 or later.

3.3.1

14th May 2020
  • Fix build scan background uploading for Gradle 6.5+

  • Support http.nonProxyHosts system property for https proxies

  • Capture concurrently used project configurations with identical names

  • Capture tasks that failed under special circumstances

Compatible with scans.gradle.com and Develocity 2020.2 or later.

3.3

5th May 2020
  • Uploads build scans in the background after the build has finished

  • Documentation improvements

Compatible with scans.gradle.com and Develocity 2020.2 or later.

3.2.1

2nd April 2020
  • Improved task dependencies capturing for composite builds

Compatible with scans.gradle.com and Develocity 2020.1 or later.

3.2

24th March 2020
  • Added support for capturing task execution plan

  • Gradle-defined proxy settings are used when publishing build scans

  • General performance improvements in dependencies capturing

Compatible with scans.gradle.com and Develocity 2020.1 or later.

3.1.1

13th December 2019
  • Improved help message when authentication is required for build scan publishing

  • Excessive logging in build scans from use of artifact transforms is suppressed

  • Mitigation if slow local host name resolution on macOS

Compatible with scans.gradle.com and Develocity 2019.4 or later.

3.1

25th November 2019
  • Support access key provisioning

  • Change response mime types from 'text/*' to 'application/*'

  • Fixed events ordering in special circumstances

Compatible with scans.gradle.com and Develocity 2019.4 or later.

3.0

16th October 2019
  • Renamed to Gradle Enterprise plugin

  • Compatibility with Gradle 6

Compatible with scans.gradle.com and Develocity 2019.3.3 or later.

2.4.2

10th September 2019
  • Added support for username, hostname and ip-addresses obfuscation

Compatible with scans.gradle.com and Develocity 2019.3 or later.

2.4.1

20th August 2019
  • More reliable capture of logging output

  • Handle overlapping IDs in dependency resolution

  • More stable end-of-build handling

Compatible with scans.gradle.com and Develocity 2019.3 or later.

2.4

8th August 2019
  • Added support for capturing all dependency selection reasons

  • Added support for capturing dependency variant details

  • Added support for capturing rich dependency version constraint information

  • Added support for capturing dependency platform and constraint details

Compatible with scans.gradle.com and Develocity 2019.3 or later.

2.3

3rd May 2019
  • Added support for plugin composite builds

  • Added support for continuous builds

  • Added support for capturing the details of annotation processors used during Java compilation

Compatible with scans.gradle.com and Develocity 2019.2 or later.

2.2.1

1st March 2019
  • More reliable capture of task input files for buildSrc

Compatible with scans.gradle.com and Develocity 2019.1 or later.

2.2

27th February 2019
  • Capture collection callback executions

  • Capture deprecation traces more compactly

  • General performance improvements in task inputs capturing

Compatible with scans.gradle.com and Develocity 2019.1 or later.

2.1

7th December 2018
  • This version is compatible with Java 8 and later

  • Capture task input files

Compatible with scans.gradle.com and Develocity 2018.5 or later.

2.0.2

6th November 2018
  • This version is compatible with Gradle 5.0 and later

  • Removed deprecated -Dscan and -Dscan=false system property, use --scan and --no-scan, respectively

  • Avoid memory leak when connecting to HTTPS server with often changing build classpath

Compatible with scans.gradle.com and Develocity 2018.4.2 or later.

2.0.1

29th October 2018
  • This version was released for compatibility with Gradle 5.0-rc-1, but is not compatible with subsequent Gradle 5.0 releases. Please use version 2.0.2 or later instead

Compatible with scans.gradle.com and Develocity 2018.4.2 or later.

2.0

17th October 2018
  • This version was released for compatibility with Gradle 5.0-milestone-1, but is not compatible with subsequent Gradle 5.0 releases. Please use version 2.0.2 or later instead

Compatible with scans.gradle.com and Develocity 2018.4.2 or later.

1.16

21st August 2018
  • Capture repositories and source repository for a resolved module component

  • Capture individual lifecycle listeners and attribute to code unit application

  • Capture Gradle build script compilation details

  • Capture deprecated usage notifications

  • Capture source of included build

Compatible with scans.gradle.com and Develocity 2018.4 or later.

1.15.2

10th August 2018
  • Fix for Kotlin script build caching

Compatible with scans.gradle.com and Develocity 2018.4 or later.

1.15.1

5th July 2018
  • Fix for potential classloader leak when using buildScan.background()

Compatible with scans.gradle.com and Develocity 2018.3 or later.

1.15

3rd July 2018
  • Support capturing expensive custom values/tags/links in the background

  • Task buildScanPublishPrevious is created lazily

  • Fixed error when using included build as plugin and in main build

Compatible with scans.gradle.com and Develocity 2018.3 or later.

1.14

12th June 2018
  • Further performance improvements

  • Removal of unnecessary implicit continuous build scan suppression

  • Capture information on lifecycle hook execution

Compatible with scans.gradle.com and Develocity 2018.3 or later.

1.13.4

18th May 2018
  • Improved performance of build scan plugin, particularly during configuration time

Compatible with scans.gradle.com and Develocity 2018.2 or later.

1.13.3

14th May 2018
  • Fix incompatibility with new continuous build features in Gradle 4.7

Compatible with scans.gradle.com and Develocity 2018.2 or later.

1.13.2

8th May 2018
  • Do not show build scan publishing information when --quiet or -q argument is present

  • Retry likely temporary network errors while publishing a build scan

Compatible with scans.gradle.com and Develocity 2018.2 or later.

1.13.1

10th Apr 2018
  • Improve performance of plugin data capture

Compatible with scans.gradle.com and Develocity 2018.2 or later.

1.13

28th Mar 2018
  • Capture console log from beginning of the build

Compatible with scans.gradle.com and Develocity 2018.2 or later.

1.12.1

13th Feb 2018
  • Fix message when terms of service are declined

Compatible with scans.gradle.com and Develocity 2018.1 or later.

1.12

12th Feb 2018
  • Capture build scans for composite builds

  • Capture original task execution time

Compatible with scans.gradle.com and Develocity 2018.1 or later.

1.11

5th Dec 2017
  • Capture test execution, dependency resolution, and project structure data from the beginning of the build

  • Improve performance of plugin data capture

  • Enhance Gradle version compatibility check

Compatible with scans.gradle.com and Develocity 2017.7 or later.

1.10.3

23th Nov 2017
  • Fix incompatibility with Android Plugin for Gradle 3.0.0

Compatible with scans.gradle.com and Develocity 2017.6 or later.

1.10.2

7th Nov 2017
  • Fix incompatibility with development builds of Gradle 4.4

Compatible with scans.gradle.com and Develocity 2017.6 or later.

1.10.1

27th Oct 2017
  • Fix incompatibility with development builds of Gradle 4.4

Compatible with scans.gradle.com and Develocity 2017.6 or later.

1.10

17th Oct 2017
  • Detect when build was run by a single-use daemon

  • Capture default charset of the JVM that executed the build

  • Capture build path of each project

Compatible with scans.gradle.com and Develocity 2017.6 or later.

1.9.1

10th Oct 2017
  • Prompt user for license agreement acceptance, if needed

  • Capture console output and network activity until closer to the end of the build

  • Limit the number and length of captured custom tags, custom links, and custom values

Compatible with scans.gradle.com and Develocity 2017.5 or later.

1.9

15th Aug 2017
  • Capture task graph calculation

  • Capture more fine-grained project configuration

  • Capture Build Cache interactions including artifact packing and unpacking

Compatible with scans.gradle.com and Develocity 2017.5 or later.

1.8

15th June 2017
  • Capture resolved requested tasks

  • Capture Build Cache configuration when Build Cache is enabled

  • Capture task inputs for each task when Build Cache is enabled

  • Capture origin build invocation id for tasks with up-to-date and from-cache outcome

  • Capture reasons why a task was not up-to-date

  • Capture GC and peak heap memory statistics

  • Capture more network download activities

  • Get notified after successful build scan publication via buildScan.buildScanPublished()

  • Build scan plugin logs at quiet level

Compatible with scans.gradle.com and Develocity 2017.4 or later.

1.7.4

29th May 2017
  • Fix incompatibility with development builds of Gradle 4.0

Compatible with scans.gradle.com and Develocity 2017.3 or later.

1.7.3

19th May 2017
  • Fix incompatibility with development builds of Gradle 4.0

Compatible with scans.gradle.com and Develocity 2017.3 or later.

1.7.2

17th May 2017
  • Fix incompatibility with development builds of Gradle 4.0

Compatible with scans.gradle.com and Develocity 2017.3 or later.

1.7.1

3rd May 2017
  • Fix incompatibility with development builds of Gradle 4.0

Compatible with scans.gradle.com and Develocity 2017.3 or later.

1.7

24th April 2017
  • Fix NPE when specifying buildScan "server" URL without schema or host

  • Overlapping output is captured as a non-cacheable reason for a task

Compatible with scans.gradle.com and Develocity 2017.3 or later.

1.6

10th February 2017
  • Capture whether task outputs are cacheable and the reason if they are not

  • Capture network download activities

Compatible with scans.gradle.com and Develocity 2017.1 or later.

1.5

11st January 2017
  • Capture whether tasks were skipped due to having no source

  • Capture whether tasks are lifecycle tasks (i.e. no actions)

  • Add "mailto:" link as custom build scan links

Compatible with scans.gradle.com and Develocity 2017.1 or later.

1.4

21st December 2016
  • Performance improvements when executing many tests

Compatible with scans.gradle.com and Develocity 2017.1 or later.

1.3

15th November 2016
  • Capture tags, links and/or values via conventional system properties

  • Reduced payload size when publishing large dependency graphs

Compatible with scans.gradle.com and Develocity 2016.4 or later.

1.2

12th October 2016
  • Capture tags, links and/or values at the end of the build via buildScan.buildFinished()

Compatible with scans.gradle.com and Develocity 2016.4 or later.

1.1.1

20th September 2016
  • Fixed issues with creating build scans for some projects via Android Studio

Compatible with scans.gradle.com and Develocity 2016.3 or later.

1.1

17th September 2016
  • Capture user-defined tags, links and arbitrary values

  • Create a build scan for every build, or every failed build

  • Create a build scan for the immediately previous build

  • Publishing a build scan is implicitly disabled when build with --offline

  • Publish a build scan over an untrusted HTTPS connection, if explicitly configured

  • Several fixes for creating build scans when executing a build through an IDE

Compatible with scans.gradle.com and Develocity 2016.3 or later.

1.0

23rd June 2016
  • Initial release

Compatible with scans.gradle.com and Develocity 2016.3 or later.

Appendix D: Compatibility with Gradle Build Tool and Develocity

Compatibility between versions of Gradle, Develocity, and the build scan plugin can be found here.

Appendix E: Verifying the signature of the plugin jar

(plugin 3.15+)

The plugin jar is published to plugins.gradle.org alongside its signature. The public key is published to https://keys.openpgp.org. You can verify the signature as follows:

$ curl -OL https://plugins.gradle.org/m2/com/gradle/gradle-enterprise-gradle-plugin/{latest-plugin-version}/gradle-enterprise-gradle-plugin-{latest-plugin-version}.jar && \
  curl -OL https://plugins.gradle.org/m2/com/gradle/gradle-enterprise-gradle-plugin/{latest-plugin-version}/gradle-enterprise-gradle-plugin-{latest-plugin-version}.jar.asc && \
  gpg --keyserver keys.openpgp.org --recv-key 7B79ADD11F8A779FE90FD3D0893A028475557671 && \
  gpg --verify gradle-enterprise-gradle-plugin-{latest-plugin-version}.jar.asc gradle-enterprise-gradle-plugin-{latest-plugin-version}.jar

The output of the last command should look similar to the following:

gpg: Signature made Thu Sep 28 16:17:46 2023 CEST
gpg:                using RSA key 893A028475557671
gpg: Good signature from "Gradle Inc. <info@gradle.com>" [unknown]
gpg:                 aka "Gradle Inc. <maven-publishing@gradle.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7B79 ADD1 1F8A 779F E90F  D3D0 893A 0284 7555 7671

This verifies that the artifact was signed with the private key that corresponds to the imported public key. The warning is emitted because you haven’t explicitly trusted the imported key (hence [unknown]). One way of establishing trust is to verify the fingerprint over a secure channel. Please contact technical support should you wish to do so.

The access key used to sign older versions of Develocity Gradle Plugin is revoked. Verifying the signature of these prior versions is no longer possible.