--- component: ROOT version: "2026.2" slug: ROOT/operations/changes canonical_url: "https://docs.gradle.com/develocity/2026.2/operations/upgrade/changes/" title: "Changes" description: "Review the changes in Develocity 2026.2, including new features, behavior changes, deprecations, and notes to plan your upgrade." keywords: - "upgrade" - "Develocity" status: current --- # 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](https://docs.gradle.com/develocity/2026.2/administration/access-control/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. > [!IMPORTANT] > 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](#read-all-build-data-permission). For a full description of the new permissions and their placement in the role editor, see [Permissions and Roles](https://docs.gradle.com/develocity/2026.2/administration/access-control/permissions-and-roles/#permissions-definitions). #### 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 ``` > [!NOTE] > 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". > [!IMPORTANT] > 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](https://docs.gradle.com/develocity/2026.2/administration/access-control/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](https://docs.gradle.com/develocity/reporting-aws/2.1/). 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](#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](https://docs.gradle.com/develocity/2026.2/reference/helm-charts/standalone/#untrusted_ssl_certificates) for standalone deployments or [the cluster equivalent](https://docs.gradle.com/develocity/2026.2/reference/helm-charts/cluster/#untrusted_ssl_certificates) 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: ```shell kubectl create configmap additional-trust --from-file=tls.crt=additional-trust.pem -n ``` 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.` 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. ```yaml 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. > [!NOTE] > 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](https://docs.gradle.com/develocity/2026.2/administration/build-acceleration/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](https://docs.gradle.com/develocity/2026.2/installation/kubernetes-installation/#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](https://docs.gradle.com/develocity/2026.2/reference/helm-charts/cluster/#edge_node) configuration for cluster installations or the [standalone equivalent](https://docs.gradle.com/develocity/2026.2/reference/helm-charts/standalone/#edge_node). ### 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.