Develocity 2024.2

⚠️ The 2024.2 release removes the legacy Built-in Build Cache component, replacing it permanently with the Build Cache service first introduced in version 2024.1. Please read the accompanying upgrade notes to ensure optimal continuity of the Build Cache service after upgrading.

Develocity 2024.2 adds Gradle, Maven, Bazel, and sbt Build Scan® build environment resource usage observability, providing visibility into CPU, memory, network, and disk utilization across the build timeline. This allows deeper insight when comparing build performance across different environments and reasoning about how resource constraints impact build time. 

Users of sbt can significantly reduce build times for compilation and testing by leveraging Develocity’s Build Cache, avoiding redundantly repetitive build work. 

Test Distribution and Predictive Test Selection users can now reason about build time savings and performance-impacting factors of these features via new Build Scan visualizations.

Read on for more details of these and other new features.

Use version 1.22 of the Develocity Maven extension, version 3.18 of the Develocity Gradle plugin, version 1.1 of the Develocity sbt plugin, version 3.1.1 of the Develocity Test Distribution agent, and version 20.0 of the Develocity Build Cache node for optimal usage of Develocity.

Use the latest versions of the Gradle Jenkins plugin, Build Scan plugin for TeamCity, Develocity Bamboo plugin, Develocity GitLab templates, GitHub Actions for Gradle and GitHub Actions for Develocity for optimal integration of your CI provider with Develocity.

Highlights

Build environment resource usage observability

The 2024.2 release of Develocity introduces build environment resource usage observability for Gradle, Maven, sbt and Bazel builds, enabling more comprehensive performance comparison between builds and more effective reasoning about how the resource usage and constraints are impacting build time.

The resource usage is visualized as part of the build timeline.

The following metrics are displayed.

CPU load

For Gradle, Maven, and sbt, the CPU utilization percentage of all processes combined, the build process, and build child processes (all processes started by the build process, along with their children) is displayed at each point in time. For Bazel, the utilization of all processes combined and the build process is displayed. 

These values allow reasoning about how CPU capacity impacted build time. For instance, a high value for the build process and/or build child process metric can indicate that increasing CPU capacity would decrease build time. Similarly, A high value for “all processes” without correspondingly high values for the build process and build child processes indicates that something else in the build environment is dominating CPU usage. 

For Gradle, Maven and sbt, the 5 most CPU-consuming processes are also listed to help determine what is dominating CPU usage.

Memory usage

For Gradle, Maven, and sbt, the amount of memory allocated to the build process, build child processes, and all processes combined is displayed alongside the total amount of memory available. The amount of memory allocated to the build process and all processes combined is displayed for Bazel.

If the reported values are close to the total available memory, the build may benefit from an environment with more memory capacity.

Disk read and write throughput

For Gradle, Maven, and sbt, the read and write bytes-per-second throughput for all storage devices are displayed. These metrics are not available for Bazel.

Network download and upload throughput

The read and write bytes-per-second throughput of all non-local network interfaces is displayed. For Bazel, version 6 or later and the `–experimental_collect_system_network_usage` flag are required to display these metrics.

A condensed version of all available metrics is also displayed on the Performance summary page.

The max, average, median, p5, p25, p75, and p95 values of each resource usage metric of Gradle and Maven builds are available via the Develocity API with the new `/api/builds/{id}/gradle-resource-usage` and `/api/builds/{id}/maven-resource-usage` endpoints. The example graph below demonstrates using this data to visualize unused CPU capacity in terms of potential build time savings.

Resource usage observability is available for:

  • Gradle builds with Develocity Gradle plugin 3.18+.
  • Maven builds with Develocity Maven extension 1.22+.
  • sbt builds with Develocity sbt plugin 1.1+ and sbt 1.7.0+.
  • Bazel builds with the restrictions mentioned above.

Build caching for sbt

This release adds a groundbreaking feature: the first fully integrated build caching solution for sbt projects.

Experience a dramatic acceleration of your sbt `compile` and `test` tasks, both locally and on your CI pipelines. By intelligently caching build artifacts, Develocity eliminates redundant work, slashing build times and supercharging your development workflow. This exclusive feature empowers you to optimize your sbt projects like never before.

Upgrade to Develocity 2024.2 and follow the setup guide to harness the full potential of sbt build caching.

Develocity Reporting and Visualization enhancements

Additional data and out-of-the-box reports have been added to the Develocity Reporting and Visualization toolchain with this release that include:

  • Gradle and Maven plugin usage, displaying which builds use which plugins and allowing filtering by plugin usage.
  • Build environment resource usage.
  • Gradle Daemon usage.

Predictive Test Selection and Test Distribution savings estimates and performance breakdown

The new “Test acceleration” page of the Tests section of Gradle and Maven Build Scans provides a detailed breakdown of the impact that Predictive Test Selection and Test Distribution had on build time.

Total build time savings estimates are provided, along with detailed per task/goal breakdowns. 

Additionally, Predictive Test Selection configuration parameters and performance metrics can now be accessed in a dedicated view on the task / goal details page:

Gradle configuration cache miss reasons

Gradle’s configuration caching feature improves build performance by caching the result of the configuration phase and reusing it for subsequent builds.

Beginning with Gradle 8.10, Gradle Build scans show the configuration cache miss reason (i.e. why a cached configuration could not be used) on the performance configuration page, providing all the configuration cache information in a single location.

Configuration cache information is now available via the Develocity API

This release also adds a new API endpoint to retrieve configuration cache information for Gradle builds. It provides whether a cached configuration was used, whether caching failed, the configuration size, the duration of store and load operations, and the cache miss reason.

See /api/builds/{id}/gradle-configuration-cache in the Develocity API reference documentation for more information.

Test size and timeout for Bazel test targets

The tests expanded section and the target details section now report the size and timeout of each Bazel test target.

IAM database authentication for user-managed AWS databases

Starting in 2024.2, Develocity instances which use a user-managed database hosted in AWS (i.e. using Amazon RDS or Aurora) can be configured to connect to the database via IAM Instance Profiles on Amazon EC2 or IAM-roles for service accounts for installations running in Amazon EKS.

This makes it possible to manage and configure access to the Develocity database without coordinating credential configuration.

Removed support for Test Distribution agents with no pool association

Develocity 2024.2 requires all Test Distribution agents to be assigned to an agent pool. To upgrade, create an agent pool, create a pool-specific registration key, and update your agents to join the pool using the new registration key.

Removed support for Test Distribution Gradle plugin

Develocity 2024.2 does not support using Test Distribution via the standalone Develocity Test Distribution Gradle plugin. Please upgrade to Develocity Gradle plugin version 3.11 and above to continue using Test Distribution.

Upgrade notes

If upgrading from a version of Develocity prior to 2024.1, be sure to also consult the release and upgrade notes for all interim versions.

After upgrading your Develocity server to the most recent version, it is recommended to upgrade your builds to use the latest version of the Develocity Gradle plugin, Develocity Maven extension, Develocity sbt plugin, Develocity Test Distribution agent, and Develocity Build Cache node. Using the latest versions of all components ensures that you benefit from security updates, bug fixes, and feature enhancements. Please check the version compatibility matrix for further reference.

It is also recommended to update your configuration of the Gradle Jenkins plugin, Build Scan plugin for TeamCity, and Develocity Bamboo plugin to reference the latest version of the Develocity Gradle plugin.

Upgrading from a version prior to 2024.1 will result in loss of Build Cache data

Develocity 2024.1 included a significant change to the built-in Build Cache service that required consideration when upgrading. Develocity 2024.2 removes transitional components that automatically migrate Build Cache data from the previous subsystem to the new subsystem.

If you are upgrading from versions older than 2024.1 directly to version 2024.2, the Build Cache service will be started with an empty cache, resulting in an increase in build times for a short duration until the build cache is repopulated. This initial repopulation typically negligibly affects overall build times as used entries are repopulated quickly on first use. 

Alternatively, you can upgrade to version 2024.1 before upgrading to version 2024.2 to preserve existing cache entries. Review the Develocity 2024.1 upgrade notes and follow the configuration guide relevant to your installation type.

Discontinuation of support for Build Cache Node versions older than 14.0 in next major release

Develocity releases starting from version 2024.3 will no longer support Build Cache Node versions older than 14.0. Patches to critical security vulnerabilities will not be backported to the affected build cache node versions, and they will no longer be available to download from the Develocity website or the Gradle DockerHub container registry.

If you have not yet upgraded Develocity to at least version 2022.4, you will need to do so to continue using a current version of the Build Cache Node. Refer to the compatibility matrix to learn more about what versions of Develocity are compatible with what versions of the Build Cache Node, and review your existing nodes to determine if you are impacted by this change.

Note that Replicated-based installation options are discontinued from version 2022.4, and Develocity is now installable only via a Helm-based approach.

If you have any questions or concerns about migrating away from older Build Cache node versions or require assistance in planning to do so, please contact Develocity support.

Renaming of taskInputsFileCapturingEnabled and goalInputsFileCapturingEnabled advanced search criteria

Develocity’s advanced search syntax allows search for builds via complex criteria, both via the user interface and via API. 

The following search criteria have been renamed in this release:

  • gradle.develocitySettings.taskInputsFileCapturingEnabled has been renamed to gradle.develocitySettings.fileFingerprintCapturingEnabled
  • maven.develocitySettings.goalInputsFileCapturingEnabled has been renamed to maven.develocitySettings.fileFingerprintCapturingEnabled.

Users may need to login more frequently due to reduced defaults for login session timeouts

Session idle timeout controls how long a user can be inactive before being logged out. Session max lifetime controls how long a user can be logged in before being logged out, regardless of activity. With the new defaults, users will need to login again after being inactive for more than one hour, or after being logged in for more than one day.

If you are using the default values, they will be updated to the new defaults when you upgrade to Develocity 2024.2. If you have customized these settings, you should review their values and update them as needed.

You can change these settings in the Admin UI under “Access Control” > “Login timeouts”. The settings can also be changed in the unattended config by setting the `auth.timeouts.ssoSessionTimeout` and the `auth.timeouts.ssoSessionMaxLifespan` properties.

Supported Kubernetes and Helm versions

The minimum supported Kubernetes version for this release is 1.28.0 (in 2024.1 release it was 1.26.0)

The minimum supported Helm version for this release is 3.13.0 (in 2024.1 release it was 3.11.0)

Please check the version compatibility matrix for further reference.

Develocity Helm Chart upgrade notes (since the last major version)

  • Develocity Container Registry
    The image registry path was changed from gradle-enterprise to develocity, inline with the renaming of the product. The `gradle` prefix and `image` suffix have been removed to simplify image names. For example:
    registry.gradle.com/gradle-enterprise/gradle-database-image:2024.1 has become registry.gradle.com/develocity/database:2024.2
    Action: The change is transparent for most users. However, the paths may need to be updated if you use an internal repository.
  • Helm & Kubernetes
    • Versions
      The minimum supported Kubernetes version for this release is 1.28.0 (in 2024.1 release it was 1.26.0).
      The minimum supported Helm version for this release is 3.13.0 (in 2024.1 release it was 3.11.0).
      Helm & Kubernetes version check is now stricter. The installation will fail if running on an unsupported version.
      Action:  If you are running on an unsupported version of Helm or Kubernetes then you should upgrade those versions. If they cannot be upgraded, the validation can be bypassed using the helmVersionOverride & kubernetesVersionOverride keys in values.yaml
    • fsGroupChangePolicy
      With Kubernetes 1.23 `fsGroupChangePolicy` has become stable. This feature allows us to hint Kubernetes on how we want filesystem permissions handled. The default setting is `Always`, but we use `OnRootMismatch` to trigger the owner and group change only when there is a mismatch in the root directory.
      Action: No action required
    • securityContext
      Some containers were defined without the `securityContext`, which implied implicit configuration from Kubernetes. We have changed this in favor of an explicit `securityContext`.
      Action: No action required
    • gradle-operator
      The `gradle-operator` can access the `kind: job` object through the Kubernetes API for operation and support-bundle purposes. 
      Action: No action required
  • Resource requirements
    • The minimum memory requirements for Develocity have been increased to 24GB.
    • The default memory of the ‘enterprise-app’ pod (and related init containers) was increased from 5 Gi to 6 Gi.
    • Legacy Built-in Build Cache node components have been removed from the chart, freeing 1 CPU & 1 Gi of memory
      Action: Please ensure that your Develocity Standalone instances or clusters have at least 24GB of memory available.
  • Components
    • Legacy built-in build cache node
      The legacy built-in build cache node component is removed and `buildCacheNode` Helm values are redundant and ignored.
      Action: Remove the `buildCacheNode` block from the Helm values.
    • gradle-embedded-object-storage
      Under load, the component inside the `gradle-embedded-object-storage` could use storage for caching purposes and consume the storage allocated to the Build Cache. Therefore, we introduced a dedicated buffer space to help this component operate correctly. Its value defaults to `5Gi` and can be modified during installation with the `objectStorage.embedded.storage.internalBuffer.capacity` value. Due to this extra storage required, any installation must “increase” the volume attached to the `embedded-object-storage` (if used). For that to happen without data loss, you must use a volume with a StorageClass compatible with Volume Expansion       (`allowVolumeExpansion: true`).
      Action: If your Storage system doesn’t support Volume Expansion, you must delete the previous volume `manually` before installing this new version.
    • objectStorage.embedded.storage.data.capacity deprecation
      To allow more granular control over features using object storage `objectStorage.embedded.storage.data.capacity` has been replaced with `objectStorage.embedded.storage.buildCache.capacity`. The storage.data configuration block is now deprecated and will be removed in an upcoming release. Until it’s removed, if `storage.buildCache.capacity` is not configured, the value from `storage.data.capacity` will be used.
      Action: `Replace objectStorage.embedded.storage.data.capacity` configuration with `objectStorage.embedded.storage.buildCache.capacity`.
    • gradle-metrics
      `gradle-metrics` uses a new persistent volume. The previous default value for the `gradle-metrics-volume` persistent volume claim size was too small for regular operation. By default, a new persistent volume, named `gradle-metrics`, with a size of 20 Gi is created. This size can be modified using the `metrics.storage.data.capacity` in your `values.yaml` configuration file. Based on your installation strategy, the previous volume may be deleted automatically.
      Action: We recommend you verify and eventually delete the previous volume named `gradle-metrics-volume` (with `-volume` at the end).
    • gradle-monitoring
      The user running `gradle-monitoring` has been changed to ID 65532:65532 (instead of 65535:65535). The change should be transparent because `fsGroupChangePolicy: OnRootMismatch` is now part of our chart.
      Action: if your Kubernetes cluster (and the Container Storage plugin) doesn’t support this, we invite you to either manually change the owner to 65532:65532 into `gradle-monitoring` attached volumes or recreate the volumes.
    • User-managed database
      A new database user ge-monitor has been introduced.
      Action: If you are running a user-managed database, you need to rerun the database setup scripts to create that user.
  • External storage
    • S3
      `s3` storage type deprecates some authentication attributes in `objectStorage.s3.credentials`.
      The list of deprecated keys is: 

      • objectStorage.s3.credentials.secretName
      • objectStorage.s3.credentials.source
      • objectStorage.s3.credentials.accessKey
      • objectStorage.s3.credentials.secretKey
        Action: If using S3, you should use one of the new `credentials.type` values (`irsa`, `instanceProfile`, `keys`), depending on your installation type (`cluster` or `standalone`). See the Kubernetes Helm Chart Configuration Guide or Standalone Helm Chart Configuration Guide for object storage configuration details.
    • Azure
      objectStorage.type: azure is deprecated and planned to be removed in an upcoming release. A new type `objectStorage.type: azureBlobStorage` has been introduced as a replacement. The new type supports a more secure authentication mechanism, WorkLoad Identity, and classic credentials with account name and key. See the Kubernetes Helm Chart Configuration Guide or Standalone Helm Chart Configuration Guide for object storage configuration details.
      Action: If using Azure, update your configuration to use the new `azureBlobStorage` configuration block.
    • Google Cloud
      objectStorage.type: googleCloud is deprecated and planned to be removed in an upcoming release. A new type, `objectStorage.type: googleCloudStorage`, has been introduced as a replacement. The new type supports a more secure authentication mechanism, `WorkLoad Identity` and `Service Account`. See the Kubernetes Helm Chart Configuration Guide or Standalone Helm Chart Configuration Guide for object storage configuration details.
      Action: If using GCP, update your configuration to use the new `googleCloudStorage` configuration block.

Changes

2024.2.1
Sep 10, 2024
  • [NEW] Build Scan: Added unavailability reason for Predictive Test Selection and Test Distribution
  • [NEW] Build Scan: Successful test executions are not marked as cross-build flaky in test views
  • [NEW] Test Distribution: Names of connecting Test Distribution agents must be unique
  • [NEW] Test Distribution: Test Distribution agents bypass the Gradle proxy when connecting to Develocity
  • [FIX] Using IAM database authentication with instance profile credentials results in an error
  • [FIX] Develocity API Maven attributes model throws an error when IP addresses are `null`
  • [FIX] Develocity API Maven plugins model throws an error when the plugin name is `null`
  • [FIX] Requesting large list of builds with build models from Develocity API may crash the application
  • [FIX] Bazel cache may return cached actions that reference blobs that are missing from the Content Addressable Storage (CAS)
  • [FIX] Logging out of Develocity sometimes results in a 502 Bad Gateway error
  • [FIX] Slow Develocity startup without internet connectivity
  • [FIX] Build Scan: Gradle projects sharing the same build script cause duplication in the performance configuration page
  • [FIX] Build Scan: The tests overview page where a Test Distribution agent was used for multiple tasks/goals results in an error
  • [FIX] Build Scan: Resource usage data with non-unique timestamps results in an error
  • [FIX] Endpoint field in S3 config-map throws nil error if not configured
  • [FIX] Build Scan: The tests overview page showing empty test work unit results in an error
2024.2
Aug 19, 2024
  • [NEW] Build Scan: Resource usage observability
  • [NEW] Support for AWS IAM database authentication (IRSA)
  • [NEW] Build Scan: Enhanced insights into Predictive Test Selection and Test Distribution time savings
  • [NEW] Build Scan: Gradle configuration cache information is available via the Develocity API
  • [NEW] Build Scan: The Tests section displays the test size and timeout value for Bazel targets
  • [NEW]Build Scan: Bazel Cache and Action Execution tab on the Performance page displays information provided by Bazel in version 6 and above.
  • [NEW] Build Scan: Gradle and Maven build profile information is available via the Develocity API
  • [NEW] Build Scan: Configuration cache miss reason is displayed in Gradle Build Scans
  • [NEW] Build Scan: Allow searching by local and remote build cache settings for Gradle and Maven
  • [NEW] Build Scan: Allow filtering for Maven unique snapshot dependencies in Gradle dependencies page
  • [NEW] Build Cache: Removed legacy built-in Build Cache node component
  • [NEW] Plugin information is available for Maven and Gradle builds via the Develocity API
  • [NEW] Removed support for Test Distribution agents with no pool association
  • [NEW] Removed support for Test Distribution Gradle plugin
  • [NEW] Object storage Helm configuration block ‘googleCloudStorage’ has been introduced for GCP. It supports ‘serviceAccount’ and ‘workloadIdentity’ credential types.
  • [NEW] Object storage Helm configuration block ‘azureBlobStorage’ has been introduced for Azure. It supports ‘accountInformation’ and ‘workloadIdentity’ credential types.
  • [NEW] Object storage Helm configuration block for S3 now supports ‘irsa’, ‘keys’ and ‘instanceProfile’ credentials.
  • [FIX] Slow startup of Develocity caused by file group ownership changes
  • [FIX] Delayed application of authentication configuration changes in a multiple replica setup shortly after startup
  • [FIX] gradle-monitoring is configured with invalid user (65535:65535)
  • [FIX] The permission config value `administerGe` is not consistent with the current product name.
  • [FIX] Under load the ‘gradle-embedded-object-storage’ decreases the space available for storage
  • [FIX] User login timeouts are too long

View Documentation View All Releases