Changes

Review the specific changes introduced in this release that require your attention or action during the upgrade process.

Review each item carefully to ensure a smooth and successful transition.

2026.2.0

Delete Build Scans Respects Project-Level Access Control

The "Delete build scans" (deleteScan) permission now respects project-level access control. Previously, a user with the "Delete build scans" permission could delete any Build Scan in Develocity, regardless of the Build Scan’s associated project. Starting in Develocity 2026.2.0, the permission only allows deleting Build Scans the user has project-level access to. This aligns the permission with the rest of the "Build data" permission group, which is already project-aware.

Additionally, the "Delete build scans" permission is no longer included in the default admin role.

Existing role assignments aren’t changed by the upgrade. Administrator roles that were created before 2026.2.0 retain the "Delete build scans" permission until an administrator removes it. Only newly created Administrator roles, and the default admin role on new installations, exclude it.

Review custom roles that grant "Delete build scans" to confirm they align with your project access-control policies. To add or remove the permission on an existing role, navigate to Administration Access control Roles.

MCP Server Access Requires the New MCP Permission

Access to both the Develocity MCP Server and the Develocity Analytics MCP Server is now gated by a new permission, "Access build data via the API and MCP" (useMcp). Previously, both servers were gated by "Access build data via the API" (exportData).

Both MCP servers now validate the access key and its permissions at the start of every request, including when listing the available tools. Previously, the Develocity MCP Server allowed listing tools and calling some tools without a valid access key.

Accessing the Develocity Analytics MCP Server still requires read access to build data across all projects, unchanged from previous releases. What’s new is an additional way to grant that access, described in Read All Build Data permission.

For a full description of the new permissions and their placement in the role editor, see Permissions and Roles.

How Existing Roles Are Migrated

During the upgrade, every role that grants "Access build data via the API" automatically gains "Access build data via the API and MCP", so anyone who could use an MCP server before the upgrade keeps that access. Roles that also grant "Access all data with or without an associated project" (accessAllDataWithOrWithoutAssociatedProject) keep cross-project access to both MCP servers, because that permission continues to elevate the new MCP permission to all projects.

This rule broadens no one’s data access. Every user who could use an MCP server before the upgrade can still do so, and no user gains access to data they couldn’t already reach. Roles that gain "Access build data via the API and MCP" could already use the MCP servers through their existing "Access build data via the API" permission. No permissions are removed, and project assignments aren’t changed.

Because every role with "Access build data via the API" gains "Access build data via the API and MCP", some roles that aren’t intended for MCP use (such as the default API Client role) also gain it. After upgrading, audit your roles and remove "Access build data via the API and MCP" from any role that shouldn’t use the MCP servers. To add or remove the permission on an existing role, navigate to Administration Access control Roles.

Develocity logs the permission changes it makes during the migration. Look for a log line similar to the following:

Example migration log line

MCP permission migration: granted USE_MCP to role(s) [api-client, mcp-eligible]; anonymous gained USE_MCP: yes

On new installations, the default Developer role includes "Access build data via the API and MCP", so developers can use the Develocity MCP Server out of the box. On upgraded installations, existing Developer roles gain it only if they already grant "Access build data via the API".

Installations managed by unattended configuration: the new permissions must be added to your configuration YAML. When an unattended configuration file changes, its contents become the source of truth and override the persisted configuration, so any role that should use the MCP servers must explicitly list useMcp (and readAllBuildData where cross-project read access is intended) in the YAML. See Configure via Unattended Configuration for an example.

New Permission for Cross-Project Read Access

A new permission, "Read all build data with or without an associated project" (readAllBuildData), grants read-only access to build data across all projects, including data that isn’t associated with a project. Unlike "Access all data with or without an associated project", it never elevates write permissions such as "Publish Build Scans" or "Read and write Build Cache data" across all projects. This makes it possible to give a user cross-project read access without also granting cross-project write access.

The Develocity Analytics MCP Server requires read access to build data across all projects, because Develocity Analytics data isn’t subject to project-level access control. This cross-project access is granted by either "Read all build data with or without an associated project" or the existing "Access all data with or without an associated project" permission.

Develocity Analytics MCP Tools Now Served at `/mcp`

This section applies to Develocity installations that use Develocity Reporting via Athena Data Export. The Develocity Reporting Kit is unaffected. See the note at the end of this section.

The Develocity MCP Server and Develocity Analytics MCP Server now share a single endpoint, /mcp, on the Develocity instance. The Analytics tools, previously available separately at /drv-mcp, are now also exposed from /mcp alongside the Develocity MCP tools. Visibility of the Analytics tools continues to be governed by the requesting user’s permissions, so a user without the cross-project read permission described in Read All Build Data permission doesn’t see them.

The legacy /drv-mcp URL on the Develocity instance is deprecated and will be removed in a future release. Existing clients configured against /drv-mcp keep working without any change at upgrade time. Migrate client configurations to /mcp before /drv-mcp is removed.

The Reporting Kit’s Analytics MCP endpoint is unchanged and continues to be served at /drv-mcp on the Reporting Kit instance.

MCP Tools Now Run in the Standalone `mcp-server` Pod

The Athena MCP tools previously ran inside the enterprise-app Pod. Starting with 2026.2.0, they run in the standalone mcp-server Pod, alongside the existing Develocity MCP tools. This simplifies scaling and observability for the MCP workload and aligns the deployment topology with the /mcp endpoint.

The operator-facing Helm schema (athenaDataExport.mcpServer.*) is unchanged. Existing values.yaml files keep working as-is. The Helm Chart ensures the Athena configuration and the /drv-mcp ingress route are properly set on the mcp-server Pod.

Because the Athena tools now run inside the same Pod, enabling them requires mcpServer.enabled: true. Add mcpServer.enabled: true to your values.yaml before upgrading if you currently enable the Athena MCP Server without the top-level Develocity MCP Server.

Composite Health Endpoint for Athena MCP

The mcp-server Pod exposes a composite Athena health endpoint at /actuator/health/athena. It aggregates two probes:

Connectivity: verifies that the configured Athena workgroup and Glue catalog are reachable using the configured credentials.
Read-only credential safety: verifies that the credentials used by the Analytics MCP Server have no write access to the build model data buckets.

When the credential probe reports DOWN, Athena MCP tool calls are rejected with an actionable error pointing operators at the same endpoint. This prevents the server from running with credentials that may not enforce the documented read-only contract.

Move `additionalTrust` under `global` in Helm Values

The network.additionalTrust field in unattended configuration is deprecated and should be migrated to the top-level global.additionalTrust section in the Helm values. The global.additionalTrust section is available in both the cluster and standalone charts and lifts the setting out of the unattended-configuration nest, so it no longer requires the surrounding version and systemPassword scaffolding.

The legacy network.additionalTrust method continues to work for existing deployments, so no immediate action is required, but it’s deprecated as of 2026.2 and may be removed in a future Develocity release.

See Trusted and Additional TLS Certificates for standalone deployments or the cluster equivalent for the full reference.

To migrate, move the contents of global.unattended.configuration.network.additionalTrust, or network.additionalTrust from a separate unattended configuration file, to global.additionalTrust.certificates in your values.yaml:

values.yaml with inline certificates

global:
  additionalTrust:
    certificates: |
      -----BEGIN CERTIFICATE-----
      MIIDfzCCAmegAwIBAgIURqPslYGu7cHXs22q3RK6e5L87PwwDQYJKoZIhvcNAQEL
      ...
      s10yB5VjVBES6A22rYwYb8mImpQiVP/mr4ao5U5m+h50l3E=
      -----END CERTIFICATE-----
      -----BEGIN CERTIFICATE-----
      DSE3a3CCAmegAwIBAgIURqPslYGu7cHXs22q3RK6e5L87PwwDQYJKoZIhvcNAQEL
      ...
      s10yB5VjVBES6A22rYwYb8mImpQiVP/mr4ao5U5m+h50l3E=
      -----END CERTIFICATE-----

Or, create a separate ConfigMap with the content from global.unattended.configuration.network.additionalTrust under the tls.crt key:

kubectl create configmap additional-trust --from-file=tls.crt=additional-trust.pem -n <release-namespace>

Then reference the ConfigMap from values.yaml:

values.yaml referencing an existing ConfigMap

global:
  additionalTrust:
    configMapName: additional-trust

Build Cache Data Can Be Stored in a Separate Bucket (Optional)

You can now store Build Cache data in a dedicated object storage bucket, separate from your Build Scans and other application data, by adding an optional cache block under your object storage provider (s3, googleCloudStorage, azureBlobStorage). Build Scans and all other application data continue to use the parent objectStorage.<provider> configuration.

A dedicated bucket lets you apply different policies to Build Cache data than to your other data, such as a different retention policy, storage class, access controls, or backup and replication strategy, for operational cost, security, or other policy reasons.

objectStorage:
  type: s3
  s3:
    bucket: develocity-application-data
    region: aws-region
    credentials:
      type: irsa
    cache:
      bucket: develocity-build-cache-data
      region: aws-region
      credentials:
        type: keys
        keys:
          accessKey: "AKIA1234ABCD7890"
          secretKey: "dfml3s9rfdlsok390wledck30rkdfs"

This change is optional and backward compatible: existing single-bucket configurations are unaffected, and no action is required to upgrade.

Like the monitoring block, the cache block is all-or-nothing: if defined, it must be complete, and no fields are inherited from the parent block.

When you add a cache bucket, existing Build Cache entries aren’t migrated to it; they remain in the previous location and are simply repopulated on demand. If you were previously using embedded object storage, its data isn’t removed automatically when you move to an external bucket.

When using Kubernetes service account-based credentials (s3 with irsa or podIdentity on Amazon EKS, googleCloudStorage with workloadIdentity on GKE, or azureBlobStorage with workloadIdentity on AKS), the application and cache buckets must be accessible from the same cloud identity, because the Develocity application pod uses a single service account. This restriction doesn’t apply to key-based credentials.

See the Kubernetes Helm Chart Configuration Guide or Standalone Helm Chart Configuration Guide for details.

Develocity Deploys a Co-located Edge Node

This release deploys a co-located Edge node to provide a local cache layer, without separately provisioning Edge infrastructure. It runs as a new edge-node Pod, and registration with Develocity is handled automatically by the Helm chart.

Before upgrading, verify your cluster has spare capacity for the new Edge node Deployment. By default, each replica requests:

CPU: 2 units
Memory: 4 GiB
Storage: 50 GiB of ephemeral volume capacity

No data is lost during upgrades or updates: the durable copy of cached data remains in the object storage connected to Develocity, and the Edge node repopulates its local cache afterward. In cluster installations the cache is a dedicated volume; in standalone installations it’s stored under global.storage.directory (/opt/gradle by default) and counts toward that volume’s capacity.

The cluster Resource Requirements already account for the co-located Edge node in the total resource requests and limits.

To scale or resize the co-located Edge node, see the Edge Node configuration for cluster installations or the standalone equivalent.

Remove the Legacy `metrics` Helm Configuration

The legacy metrics component, a standalone VictoriaMetrics Pod (gradle-metrics), has been removed from the chart. The modern monitoring stack under monitoring.metrics (containers inside the gradle-monitoring Pod) is unaffected and continues to handle metrics collection and storage.

If your values.yaml contains a top-level metrics: block, delete it before upgrading. Settings under monitoring.metrics are unrelated and should stay.