Other CI Systems

Expose your Develocity access key as a secret environment variable named DEVELOCITY_ACCESS_KEY in your CI system. Consult your CI system’s documentation for how to store and expose secret values securely.

The access key value uses the format «server host name»=«access key»:

The plugin reads DEVELOCITY_ACCESS_KEY at build time and uses it to authenticate with your Develocity server.

With Gradle 9.5.0 or later, you can instrument builds without adding the Develocity plugin to your project’s settings.gradle. In that case, configure the Develocity server URL via the COM_GRADLE_DEVELOCITY_URL environment variable:

For standard Gradle plugin setups, configure the server URL in settings.gradle instead. For Maven builds, configure the server URL in .mvn/develocity.xml. For other build tools, refer to the relevant plugin documentation.

If your CI system issues OIDC tokens, supply one in the same DEVELOCITY_ACCESS_KEY variable from Set the Access Key, in place of the stored access key.

Obtain an OIDC token from your CI provider however it issues one, then set the host-qualified value:

The Gradle plugin rejects a bare token, so keep the host name prefix.

Because no Develocity CI integration exchanges the token here, the build uses the OIDC token directly, so it must stay valid for the whole build. Provider OIDC tokens are often short-lived, a few minutes, which suits short builds or providers that can issue longer-lived tokens. For a Develocity access token that lasts the whole build regardless of the OIDC token’s lifetime, use a CI system with a Develocity integration that performs the exchange, such as GitHub Actions or GitLab CI.

After your first CI run, open your Develocity server and navigate to Build Scan. Your build should appear there. Install the Common Custom User Data plugin to tag builds as CI and enrich each Build Scan with the CI system name, Git branch, and commit SHA.