skip to content

What is the Develocity (formerly Gradle Enterprise) Settings plugin used for, and why is it applied in settings rather than per project?

level: middleimportance: should knowfreq 40%

answer

  1. build scans + remote cache + PTS
  2. build-wide, one per invocation
  3. develocity {} on Settings
  4. buildCache {} also Settings-level
  5. renamed from gradle-enterprise

basics

~10 s

The com.gradle.develocity Settings plugin enables build-wide features: build scans, the remote build cache, and predictive test selection. It's applied in settings because those features span the whole build, not one project.

solid answer

~40 s

`com.gradle.develocity` is applied in the `plugins {}` block of `settings.gradle.kts`. It turns on **build scans** (a shareable, detailed record of a build — tasks, timings, dependencies, failures), the **remote build cache** (so task outputs are reused across machines and CI), and **predictive test selection**. These are build-wide concerns: the build cache, scan publishing, and cache server URL apply to every project in the build, so they belong on the `Settings` object via a `develocity {}` configuration block. Applying it per project would mean inconsistent or duplicated configuration. The plugin replaced the older `com.gradle.enterprise` ID; legacy builds may still use the enterprise plugin and the `gradleEnterprise {}` block.

code

kotlin · 11 lines
kotlin
// settings.gradle.kts
plugins {
    id("com.gradle.develocity") version "3.18"
}

develocity {
    buildScan {
        termsOfUseUrl = "https://gradle.com/terms-of-service"
        termsOfUseAgree = "yes"
    }
}

go deeper

for a junior

Know it enables build scans and is applied in settings.gradle.kts.

for a middle

List the three capabilities (scans, remote cache, predictive test selection) and explain why they're build-wide.

for a senior

Tie it to caching strategy: configure push-only-on-CI, scan-on-failure, and cache key correctness.

for a principal

Discuss rolling Develocity org-wide via a published convention Settings plugin, server hosting, ToS auto-acceptance, and data governance.

## What Develocity is Develocity (rebranded from *Gradle Enterprise*) is a commercial platform for build observability and acceleration. Its Gradle integration is a **Settings plugin** because the things it controls are properties of the whole build invocation, not of any single project. Three headline capabilities: ### 1. Build Scans A build scan is a persisted, shareable web record of one build: every task, its duration and cache outcome, the dependency graph, applied plugins, environment, deprecation warnings, and failures with full stack traces. You publish one with `--scan` or by configuration. Scans are invaluable for diagnosing flaky/slow builds across a team. ### 2. Remote Build Cache Gradle's local build cache stores task outputs keyed by a hash of inputs. The **remote** cache (a Develocity server, or `HttpBuildCache`) shares those outputs across developers and CI, so if CI already built an artifact with identical inputs, your machine downloads the result instead of rebuilding. ### 3. Predictive Test Selection Uses historical data to run only the tests likely affected by a change, cutting test time. ## Why settings, not project Build scans, cache server endpoints, and predictive test selection are **build-global**: there is one cache backend, one scan per invocation. Configuring them on each `Project` would be repetitive and could conflict. So Develocity exposes a `develocity {}` block on the `Settings` object: ```kotlin // settings.gradle.kts plugins { id("com.gradle.develocity") version "3.18" } develocity { server = "https://develocity.example.com" buildScan { termsOfUseUrl = "https://gradle.com/terms-of-service" termsOfUseAgree = "yes" publishing.onlyIf { it.buildResult.failures.isNotEmpty() } } } buildCache { remote(develocity.buildCache) { isEnabled = true isPush = System.getenv("CI") != null } } ``` Note `buildCache {}` is also a `Settings`-level block — another reason cache config lives here. ## Naming / history - Old ID: `com.gradle.enterprise` with a `gradleEnterprise {}` block. - New ID: `com.gradle.develocity` with a `develocity {}` block. - For free, scan-only usage there is also the lighter `com.gradle.build-scan` style integration, but the full Settings plugin is the standard. The takeaway: Develocity is the canonical example of *why* build-wide features are configured by a Settings plugin.

  • Why is the build cache configured in settings.gradle.kts and not build.gradle.kts?
    Because `buildCache {}` is a property of the whole build (one local + one remote backend shared by all projects), so it lives on the Settings object.
  • What was the Develocity plugin previously called?
    `com.gradle.enterprise` (Gradle Enterprise), configured through a `gradleEnterprise {}` block before the rename to Develocity.

saying these in an interview costs you the question

  • Claiming build scans require a paid server — basic scans can publish to the free gradle.com service.
  • Saying you'd apply Develocity in each subproject's build.gradle.kts.

context

resolving links…