---
component: ROOT
version: "2026.3"
slug: ROOT/integrations/gitlab-ci
canonical_url: "https://docs.develocity.ai/2026.3/integrations/ci/gitlab-ci/"
title: "GitLab CI"
description: "Integrate Develocity with GitLab CI using the Develocity GitLab templates to configure the Gradle plugin or Maven extension and publish a Build Scan."
keywords:
  - "CI"
  - "continuous integration"
  - "GitLab templates"
  - "Build Scan"
status: current
---

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

# GitLab CI

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

> [!NOTE]
> You have a Develocity server URL and access key. GitLab CI/CD is configured for your project or group. For sbt, npm, and Python builds, the Develocity plugin or extension must already be configured in your build. See the documentation for sbt, npm, or Python. For Gradle and Maven builds, the templates configure the plugin or extension at the CI level, so no changes to your build scripts are required. See the documentation for Gradle or Maven.

<a id="use-the-develocity-gitlab-templates"></a>

## Use the Develocity GitLab Templates

The [Develocity GitLab templates](https://github.com/gradle/develocity-gitlab-templates) configure the Develocity Gradle plugin or Maven extension at the CI level, publishing a Build Scan without modifying your Gradle or Maven build scripts.

Include the templates in your `.gitlab-ci.yml` and set the required CI/CD variables. Refer to the [Develocity GitLab Templates repository](https://github.com/gradle/develocity-gitlab-templates) for the full `include:` configuration and the list of supported variables.

<a id="store-the-access-key-as-a-cicd-variable"></a>

## Store the Access Key as a CI/CD Variable

Store your Develocity access key as a [GitLab CI/CD variable](https://docs.gitlab.com/ci/variables/) named `DEVELOCITY_ACCESS_KEY`. Mark it as **Masked** to prevent the value from appearing in job logs.

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

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

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

## Authenticate With Workload Identity

Instead of the stored CI/CD variable from [Store the Access Key as a CI/CD Variable](#store-the-access-key-as-a-cicd-variable), mint an OIDC token for each job and set the same `DEVELOCITY_ACCESS_KEY` from it. The [Develocity GitLab templates](#use-the-develocity-gitlab-templates) exchange it for a short-lived Develocity access token the same way they exchange an access key.

> [!NOTE]
> Configure a Workload Identity rule in Develocity before using this flow, using the GitLab CI provider example on that page for the issuer and audience. The aud you set on the job’s ID token must match the Audience configured on that rule.

Add an `id_tokens:` block to the job and set `DEVELOCITY_ACCESS_KEY` from the minted token, in host-qualified `«server host name»=«token»` form:

```yaml
build:
  id_tokens:
    DV_OIDC_TOKEN:
      aud: https://develocity.example.com
  before_script:
    - export DEVELOCITY_ACCESS_KEY="develocity.example.com=$DV_OIDC_TOKEN"
  script:
    - ./gradlew build
```

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

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

## Verify the Integration

After your first pipeline 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 Git branch, commit SHA, and a link back to the GitLab CI pipeline.