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.1.0

Liveness, Readiness, and Startup Probes Available

This release introduces a new probe mechanism offering unified and pre-configured liveness, readiness, and startup probes.

These probes are pre-configured with sensible defaults and apply to all deployment types. If you encounter issues, raise a ticket with Develocity support. You can disable this mechanism using the following entry in your values.yaml:

global:
  internal:
    probesV2:
      enterprise:
        enabled: false
      operator:
        enabled: false
      testDistribution:
        enabled: false

Port Names Are Unified and Consistent Across Pods

As part of the standardized probe initiative, this release applies consistent naming to all component ports.

The http-monitoring port (9090) is now the designated port for liveness, readiness, and startup probes, as well as all internal component operations. Other ports have been introduced or renamed, but these changes have no impact on standard deployments.

These updates affect all Kubernetes resources where named ports may be referenced, including:

  • Ingress

  • Service

  • Deployment (specifically containerPorts)

  • NetworkPolicy

If your configuration uses strategic merge patch, JSON patch, or Helm post-rendering logic that references specific port names, verify and update these definitions before deployment to ensure compatibility.

Default Cache Size Increased from 10 GiB to 50 GiB

The default Build Cache size has increased from 10 GiB to 50 GiB. If your installation uses embedded storage with the previous default cache size, this change requires action before upgrading. You must either configure the cache to retain the 10 GiB size or resize the storage to use the new 50 GiB default.

If your installation uses the default 10 GiB size on the default embedded storage solution and you want to keep that value, apply the following change to your Helm values:

values.yaml
objectStorage:
  embedded:
    buildCache:
      capacity: 10Gi (1)
1 The new default is 50 GiB, so you must specify 10 GiB explicitly to retain it.

This applies to standalone setups, but is more important in cluster installations because the change attempts to resize the PersistentVolumeClaim (PVC). If the PVC doesn’t support resizing, PVC creation fails and the Pods don’t start.

To adjust the cache size to the new default (50 GiB) or to any other value, follow these steps:

  1. Adjust the values YAML to use your desired value (not needed when moving to the new 50 GiB default):

    objectStorage:
      embedded:
        buildCache:
          capacity: 50Gi
  2. For cluster installations with PVCs that don’t support resizing, scale down the instance:

    kubectl scale --replicas=0 deployment --all -n develocity
  3. Delete the gradle-embedded-object-storage PVC. This also deletes the current contents of the cache.

    kubectl delete pvc -n develocity gradle-embedded-object-storage
  4. Run the upgrade and scale the replicas back up. The PVC recreates with the new value (75 GiB, as there is by default another 25 GiB of other internal component data).

    kubectl get pvc -n develocity gradle-embedded-object-storage
  5. Set the Target storage size in the UI or unattended configuration to match your Helm value (default 51200 MiB). In the UI, navigate to https://<DEVELOCITY_URL>/admin/build-cache/configuration and update the value. After saving and applying, the cache uses the new size.

New Subcomponent for Monitoring Database Metrics

This release adds a new container to gradle-monitoring that provides application metrics from the database. This component is used only for internal operations, as part of the support-bundle generation.

The component runs as a new container in the gradle-monitoring Pod, using a dedicated ge_monitor database role to connect to the database, embedded or user-managed.

The global.openshiftInstallation Flag Is Removed

The global.openshiftInstallation flag has been removed in this release. If this flag is still present in your values.yaml, remove it before upgrading. Otherwise, Helm schema validation fails.

global:
  openshiftInstallation: false # <-- remove this line

There is no change in functionality. The flag was deprecated and the only allowed value was false.

If you previously used global.openshiftInstallation: true, refer to the 2025.2 Upgrade Guide for migration instructions before proceeding.

Components Now Use seccompProfile.type: RuntimeDefault

All components now set seccompProfile.type: RuntimeDefault. This restricts system calls and aligns with the Kubernetes principle that explicit security configurations are preferable to implicit runtime behaviors.

Develocity MCP Server and Develocity Analytics MCP Server require dedicated license entitlements

Access to the MCP Server and Analytics MCP Server is now controlled by dedicated license entitlements. Licenses existing to date have been updated to include these new entitlements.

2025.4.5

gradle-monitoring Subcomponent for Logs Is Modified

The log-collector component used inside gradle-monitoring has been replaced by a new one that consumes less CPU and memory.

The component is bundled in a new image (registry.gradle.com/develocity/monitoring-vector). Adjust your infrastructure or installation process to reflect this addition (image cache or registry, firewall rules for image download).