---
component: ROOT
version: "2026.3"
slug: ROOT/integrations/other-ci
canonical_url: "https://docs.develocity.ai/2026.3/integrations/ci/other-ci/"
title: "Other CI Systems"
description: "Use environment variables to connect Develocity to any CI system and publish a Build Scan from your Gradle, Maven, sbt, npm, or Python builds."
keywords:
  - "CI"
  - "continuous integration"
  - "DEVELOCITY_ACCESS_KEY"
  - "Build Scan"
status: current
---

<!-- llms-index: https://docs.develocity.ai/llms.txt -->

# Other CI Systems

<a id="preamble"></a>

Any CI system that supports environment variables can run Develocity-instrumented builds and publish a Build Scan.

> [!NOTE]
> The Develocity plugin or extension is configured in your build. See the documentation for Gradle, Maven, sbt, npm, or Python. You have a Develocity server URL and access key.

<a id="set-the-access-key"></a>

## Set the Access Key

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»`:

```properties
develocity.example.com=7w5kbqqjea4vonghohvuyra5bnvszop4asbqee3m3sm6dbjdudtq
```

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

<a id="configure-the-server-url-for-gradle"></a>

## Configure the Server URL for Gradle

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:

```shell
COM_GRADLE_DEVELOCITY_URL=https://develocity.example.com
```

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.

<a id="authenticate-with-workload-identity"></a>

## Authenticate With Workload Identity

If your CI system issues OIDC tokens, supply one in the same `DEVELOCITY_ACCESS_KEY` variable from [Set the Access Key](#set-the-access-key), in place of the stored access key.

> [!NOTE]
> Configure a Workload Identity rule in Develocity before using this flow. The audience your CI system issues the token for must match the Audience configured on that rule.

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

```properties
DEVELOCITY_ACCESS_KEY=develocity.example.com=«OIDC token»
```

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.

<a id="verify-the-integration"></a>

## Verify the Integration

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](https://docs.develocity.ai/2026.3/using-develocity/common-custom-user-data/) to tag builds as CI and enrich each Build Scan with the CI system name, Git branch, and commit SHA.