Earlier versions of Develocity require applying the Develocity Test Distribution Gradle plugin in addition to the Develocity Gradle plugin as a prerequisite of using Predictive Test Selection. Its plugin ID is com.gradle.enterprise.test-distribution (last version: 2.3.5).
From version 3.12 onward, you can also use the com.gradle.enterprise.testing.annotations.MustRun annotation from the gradle-enterprise-testing-annotations project without any additional configuration other than the dependency.
From version 1.16 onward, you can also use the com.gradle.enterprise.testing.annotations.MustRun annotation from the gradle-enterprise-testing-annotations project without any additional configuration other than the dependency.
I'm trying to use the gradle-enterprise-maven-extension for Maven. My understanding is that you can decide to use a remote cache via a Gradle Enterprise server and/or a local cache. I wanted to disable any remote cache and enable the local one.
When I run maven with the gradle goal logging enabled, the extension notifies my that the build cache is disabled and at the end the $HOME/.m2./.gradle-enterprise/build-cache directory does not exist. This is the command and output:
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.
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.
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 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.
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.
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.
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//pending-uploads/*.log.
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.
For versions 1.2.3+, this identifier is stored under .mvn/.gradle-enterprise/gradle-enterprise-workspace-id. The .mvn/.gradle-enterprise folder should NOT be committed under version control.
For versions [1.2 - 1.2.2], the identifier is stored under .mvn/gradle-enterprise-workspace-id.txt. The file is migrated to the new location when upgrading to a Develocity Maven extension version that is at least 1.2.3. The .mvn/gradle-enterprise-workspace-id.txt file should NOT be committed under version control.
Develocity is a commercial product for companies that can be hosted on their own systems and ships with a build scan server and a Build Cache backend implementation. scans.gradle.com is a build scan server available for free, hosted by Gradle Inc.
Develocity access keys are stored inside the Maven user home directory (/.m2 by default), at .gradle-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.
This data is used for build comparison and Predictive Test Selection, which both are only available in Develocity. If you are using scans.gradle.com, it is not recommended that you enable capture of goal input files.
With Maven extension v1.6.3+, you can register obfuscation values on the gradle-enterprise.xml. These will always be applied, even in case of very early build failures, that would prevent programmatic configuration via the BuildScan API. If the BuildScan API gets eventually called, obfuscation functions registered with it will have precedence over the values defined via XML.
Sometimes you might encounter a situation where a goal execution is not avoided by using the Build Cache although you would expect it to be. For example, if you run the same build twice without any changes, the outputs of all supported goals should be retrieved from the local Build Cache (if it is enabled). If this is not the case, this almost always is caused by unstable inputs, e.g. a timestamp being added to a file by some build logic. In order to identify which inputs change between builds the Maven build comparison feature can be used. Simply run the same Maven build twice and compare those two builds. To make it easier to find unstable input files capturing of goal input files should be explicitly enabled using -Dgradle.scan.captureGoalInputFiles=true
Using the native-maven-plugin from org.graalvm.buildtools will prevent caching the output of the Surefire test goals. The native-maven-plugin will register an untracked output folder under target/test-ids which causes the goals to become uncacheable. To solve this, declare the folder as an output for the Surefire plugin in the configuration of the gradle-enterprise-maven-extension as follows:
/conf/gradle-enterprise.xml is used to set global defaults for a given Maven installation. This is useful when you ship a custom Maven distribution to your teams. The location of this configuration file can be overwritten using the -Dgradle.global.config argument. This can be useful for CI environments where changing the Maven installation is not possible.
/gradle-enterprise.xml is used for organization-wide or team-wide configuration and overrides the global configuration. This allows to package a gradle-enterprise.xml file in the root of a custom extension jar that can be reused across projects.
/.m2/gradle-enterprise.xml is used for user-specific configuration and overrides the project configuration. The location of this configuration file can be overwritten using the -Dgradle.user.config argument. This can be useful for CI environments where changing the user home is not possible.
Be sure to include the XML namespace declarations to get auto-completion in your IDE. The latest version of the schema is available at -enterprise-maven.xsd, or you can get a specific schema version by appending the Develocity Maven extension version to the schema location, e.g. -enterprise-maven-1.20.xsd. IntelliJ IDEA will mark unknown schemas as missing and they have to be explicitly fetched via the quick fix dialog (Alt + Enter). There is an open issue to make this more user-friendly.
The following example shows how to use both expression types to configure local and CI builds with a single gradle-enterprise.xml file. It uses the JENKINS_URL environment variable (which is present in builds on Jenkins) to determine whether the build is running locally or on CI. Based on that, it enables the local Build Cache and background build scan upload only for local builds but enables writing to the remote Build Cache only for CI builds. Moreover, it determines the URL of the remote Build Cache based on the fictional REGION environment variable. Lastly, it uses Maven-style expressions to configure the remote Build Cache credentials based on custom environment variables that are typically injected by the CI server.
When using Develocity Maven extension version < 1.16, you must instruct Maven to search for goal prefixes within the com.gradle plugin group. You must add the following code snippet to your /.m2/settings.xml or $maven.home/conf/settings.xml.
A Build Scan is a shareable record of a build that provides insights into what happened and why. You can create a Build Scan at scans.gradle.com for the Gradle, Maven and sbt build tools for free.
Publishing a Build Scan to scans.gradle.com transmits information about your Gradle, Maven and sbt builds and their environment to Gradle's servers. The information is only accessible via a randomly generated link, printed at the end of the build. You can delete the Build Scan when you are finished.
Declare the Develocity Maven extension in the .mvn/extensions.xml file in your root project. com.gradle gradle-enterprise-maven-extension 1.20 2. Run your build mvn install Learn more You can even extend each Build Scan with custom data, and more. Learn how via the Develocity Maven Extension User Manual.
df19127ead