This page is a reference for integrating Gradle with Jenkins.

The Gradle plugin

The Gradle plugin adds first-class Gradle support to Jenkins. Install it from Manage Jenkins → Plugins → Available plugins.

The plugin provides:

  • An Invoke Gradle script build step for Freestyle projects.

  • Automatic detection of Build Scan® links published during the build.

  • A withGradle pipeline wrapper that captures Build Scan links in Pipeline jobs.

  • Optional auto-injection of the Develocity Gradle plugin for centralized build analytics.

Freestyle projects

Add an Invoke Gradle script build step and configure it:

Field Description

Use Gradle Wrapper

When selected, Jenkins runs the gradlew script from the workspace. Recommended for all projects — ensures the build uses the Gradle version checked into the repository.

Wrapper location

Relative path to gradlew if it is not in the workspace root.

Tasks

Space-separated Gradle tasks, e.g. clean build. Defaults to the project’s default task when blank.

Switches

Command-line flags passed to Gradle, e.g. --scan -s --no-daemon.

Build File

Relative path to build.gradle or build.gradle.kts if it is not in the workspace root.

System properties

-D properties forwarded to the Gradle JVM.

Project properties

-P properties passed to the Gradle build.

Gradle installation

A pre-configured Gradle installation from Manage Jenkins → Tools. Ignored when Use Gradle Wrapper is selected.

Job parameters are automatically quoted by the plugin, so special characters in property values are handled correctly.

Pipeline projects (Jenkinsfile)

For Pipeline-as-code, invoke the Gradle Wrapper via sh (Linux/macOS) or bat (Windows) and wrap it with withGradle to capture Build Scan links:

pipeline {
    agent any

    tools {
        jdk 'jdk-21'
    }

    stages {
        stage('Build') {
            steps {
                withGradle {
                    sh './gradlew build'
                }
            }
        }

        stage('Test') {
            steps {
                withGradle {
                    sh './gradlew check'
                }
            }
            post {
                always {
                    junit '**/build/test-results/test/TEST-*.xml'
                }
            }
        }
    }
}

  • tools { jdk 'jdk-21' } selects a JDK configured in Manage Jenkins → Tools. The Gradle Wrapper handles the Gradle distribution, so no Gradle tool entry is required.

  • withGradle { …​ } tells the Gradle plugin to scan the build output for Build Scan links and display them on the build page.

  • The junit post step archives test results so they appear in the Jenkins test report.

To search for Build Scan links across an entire pipeline run (for example when Gradle is invoked inside a shell script without withGradle), add a findBuildScans() step at the end of the pipeline.

Scripted pipeline

In a scripted pipeline, use withGradle the same way:

node {
    stage('Build') {
        checkout scm
        withGradle {
            sh './gradlew build'
        }
    }
}

Using the Gradle Wrapper

The Gradle Wrapper is the recommended way to invoke Gradle on Jenkins. With the Wrapper checked into the repository, build agents need only a JDK — no Gradle installation is required.

In Freestyle projects, select Use Gradle Wrapper in the build step. In Pipelines, call ./gradlew directly via sh or bat.

Build Scans and Develocity integration

Capturing Build Scan links

The Gradle plugin automatically detects Build Scan URLs printed to the console log. In Freestyle projects, this works out of the box. In Pipelines, wrap Gradle invocations with withGradle or call findBuildScans() at the end of the pipeline.

Enriched Build Scan display

When a Develocity server URL and access key are configured (see below), the plugin fetches metadata from the Develocity API and displays project name, requested tasks, build tool version, and outcome alongside the Build Scan link.

Enriched metadata requires a Develocity server — it is not available for scans published to the public scans.gradle.com.

Auto-injecting the Develocity plugin

The Gradle plugin can automatically inject the Develocity Gradle plugin into builds without modifying project sources. Configure this under Manage Jenkins → System → Develocity:

Setting Description

Develocity server URL

URL of your Develocity instance. Can optionally be enforced over project-defined URLs.

Develocity Gradle plugin version

The version to inject into builds.

Allow untrusted server

Accept self-signed TLS certificates.

VCS repository filter

Newline-delimited patterns (+:repo-pattern, -:repo-pattern) to include or exclude repositories from injection.

Enabled/disabled agent labels

Control which Jenkins agents receive injection. Disabled labels take precedence.

Short-lived access tokens

Preferred over long-lived access keys. Requires Develocity 2024.1+. Tokens are retrieved at job execution time.

To auto-accept Build Scan terms of use without plugin injection, configure the Develocity plugin directly in settings.gradle[.kts]:

plugins {
    id("com.gradle.develocity") version "3.18.1"
}

develocity {
    buildScan {
        termsOfUseUrl = "https://gradle.com/help/legal-terms-of-use"
        termsOfUseAgree = "yes"
        publishing.onlyIf { true }
    }
}

Test reporting

Gradle produces JUnit-compatible XML reports under build/test-results/. Archive them with the junit step so Jenkins displays test counts, durations, and failure details on the build page:

post {
    always {
        junit '**/build/test-results/test/TEST-*.xml'
    }
}

In Freestyle projects, add a Publish JUnit test result report post-build action with the same glob pattern.

Caching and performance

Jenkins agents are typically long-lived, so ~/.gradle (the Gradle User Home) is preserved between builds on the same agent. Downloaded dependencies, Wrapper distributions, and the local build cache persist automatically.

For ephemeral or distributed agents, consider:

  • A Gradle Remote Build Cache to share task outputs across agents.

  • A repository manager (Artifactory, Sonatype Nexus) to proxy external dependencies within your network.

  • The --no-daemon flag for short-lived agents where daemon startup cost is wasted.

Managing credentials

Store publishing tokens, signing keys, and other secrets as Jenkins credentials. Bind them to environment variables in a Pipeline with withCredentials:

withCredentials([string(credentialsId: 'publish-token', variable: 'PUBLISH_TOKEN')]) {
    withGradle {
        sh './gradlew publish'
    }
}

Access the variable in build.gradle[.kts] with System.getenv("PUBLISH_TOKEN") or providers.environmentVariable("PUBLISH_TOKEN").