Develocity 2024.1

The 2024.1 release of Develocity marks the general availability of Develocity for sbt, the most popular build tool for Scala projects. This release is packed with several features that substantially enhance the sbt Build Scan experience. Sbt build scans now provide visibility on all tasks executed during a build execution, report the result of each executed test, surface flaky test executions, and enable investigating tests and build failures across time.

You can publish an sbt Build Scan directly to the free scans.gradle.com service. If you are interested in connecting your sbt builds to your Develocity installation, please contact your customer success representative.

The Timeline page of an sbt Build Scan provides a swimlane-style visualization of a build’s tasks, including detailed information about each executed task.

A lot occurs when you invoke common tasks such as compile, test, and package. The timeline helps tame this complexity, enabling you to identify and remediate the bottlenecks in a build.

See this pull request on the Apache Pekko project or this one on the Spotify Scio project for two real-world examples demonstrating how the timeline helps surface and address build bottlenecks.

The Console log can now be filtered by a given task’s execution name, which is particularly useful for the intertwined logging of builds executed in parallel.

The Tests section of an sbt Build Scan reports the results of all executed tests, including flaky tests.

The Slowest tests tab on the Tests page helps quickly identify the longest running tests across a build, which can be particularly useful for larger builds with several modules that contain tests.

This release of Develocity enables identifying and investigating test failure patterns, including flaky tests, on sbt builds. The charts at the top of the Tests page separate builds with failed tests from those hampered by flakiness. By default, a flaky test execution doesn’t result in a test failure.

Each test suite that you run can be explored, for instance, to understand which of the tests were a source of flakiness.

Read the Failure Analytics product page to learn more.

It’s now possible to identify and investigate failure patterns across sbt builds. The top failures report shows the most frequent failures, grouped by cause and charted over time.

Develocity separates source code verification failures, such as compiling, linking, testing, and linting from non-verification failures. This surfaces problems such as build configuration or infrastructure failures that are likely unexpected and disruptive.

Selecting a failure initiates a search for all occurrences of that failure, along with breakdowns by day, user, build hostname, and common tags.

You can search for failures that you’re interested in by their message. For example, you can search for https://your.artifactoryhost.com/ to quickly see how often builds fail due to an offline repository.

Read the Failure Analytics product page to learn more.

You can configure the Develocity sbt plugin to retry failed tests up to a user-specified maximum. If a test succeeds after a retry, the test is reported as FLAKY in the published Build Scan. This simplifies the task of identifying flaky tests while also enhancing the resilience of sbt builds.

To enable this functionality and allow up to three retries, include the following in your develocityConfiguration:

ThisBuild / develocityConfiguration :=
DevelocityConfiguration(
testRetryConfiguration = TestRetryConfiguration()
.withMaxRetries(3)
// rest of your Develocity configuration
)

By default, failed tests passing on retry prevent the test task from failing. This means that a build never fails because of a flaky test unless the maximum number of retry attempts is reached. This behavior can be changed, and it’s possible to fail a build if flaky tests are detected.

The sbt Develocity Common Custom User Data plugin enhances published build scans by adding a set of tags, links, and custom values that have proven useful for many projects built with Develocity. See the Develocity sbt plugin User Manual and the sbt Develocity Common Custom User Data plugin repository for more information.

You can now delve deeper into configuration caching within a Gradle Build Scan. The Configuration tab of the Performance page is updated to show the overall result: HIT, MISS, or FAILED.

Furthermore, the Configuration tab also provides details about the configuration cache entry size on disk, which helps understand why it might be slow to store or load. If it’s a HIT, you can conveniently navigate to the origin build responsible for creating the configuration cache entry.

Develocity 2024.1 provides several additions and improvements for Bazel build scans, including the following:

• Highlights Bazel’s exit codes for failing builds and tests to quickly differentiate a parsing error, build failure, test failure, or OOM error
• Captures and displays stderr and stdout from failing actions, such as compilation errors
• Gracefully handles aborted builds, displays test failures in the Failure page, and properly reports when tests time out

In addition, Develocity now displays Bazel’s reported Critical Path on the Timeline page to let users quickly see the longest chain of dependent actions with regard to wall execution time of Bazel build and test commands. Also, users can now directly download the Bazel profile.json file from the Timeline page to load into third-party profile viewers.

Tests executed remotely on Test Distribution agents can now be debugged using the standard debugging tools in your IDE. This allows developers to diagnose issues with tests that only occur when executed remotely. Moreover, this allows for a consistent experience when remote execution is preferred.

When you enable project-level access control, it’s now possible to restrict the usage of Test Distribution agent pools to specific project groups. This is useful when Test Distribution agents provide access to secured resources, such as databases or other services, that should not be accessible to all projects. To prevent misconfiguration, such agent pools require pool-specific registration keys for authentication.

See Project groups in the Develocity Administration Manual for additional information about configuring project groups.

A new endpoint provides information about individual artifact transform executions for Gradle builds. The endpoint allows users to monitor the performance of artifact transform executions, particularly those related to the build cache.

See Get the artifact transform execution list of a Gradle build in the API reference documentation for more information.

This release adds a new endpoint to retrieve deprecation information for Gradle builds. The endpoint identifies the kinds of deprecations a build currently has and how often each kind appears in the build. Use the endpoint to monitor whether a build is ready for upgrade to the next major Gradle version.

See Get the Gradle Build Tool deprecations of a Gradle build in the Develocity API reference documentation for more information.

Previously, arbitrary and custom analysis of Develocity build data required creating or configuring systems to pull data from the Develocity API into an in-house system. With this release of Develocity, we are making this much easier to achieve by removing the need to create custom applications and providing specific support for a standalone end-to-end analysis stack using the Trino Distributed SQL query engine and the Grafana data visualization platform, or AWS Athena and Grafana for users on the AWS platform.

The standalone end-to-end stack, known as the Develocity Reporting Kit, can be installed separately from the Develocity server. It is available to all Develocity users at no additional cost.

The stack includes a set of useful predefined Grafana visualizations that visualize several aspects of Develocity build data, including network usage and dependency downloading to the slowest Gradle tasks and Maven goals across all builds and projects. These visualizations are based on Trino/Athena queries and also serve as useful starting points for developing custom queries and visualizations.

Please contact Develocity support to get started if you are interested in installing the Develocity Reporting Kit using the AWS-native equivalent stack, a native stack for a different cloud platform, or using different query or visualization tools.

Before 2024.1, access keys were the only available mechanism for builds to authenticate with Develocity, which are long-lived access credentials. Develocity now supports authenticating with short-lived access tokens. An access token is similar to an access key, except it is only valid for a short period of time and can be limited in scope.

See the appropriate manual for your build tool for instructions on how to generate and use access tokens:

• Develocity Gradle Plugin User Manual – Short-lived access tokens
• Develocity Maven Extension User Manual – Short-lived access tokens
• Develocity sbt Plugin User Manual – Short-lived access tokens
• Develocity Bazel Plugin User Manual – Short-lived access tokens

Develocity provides a build cache service for Gradle, Maven, and Bazel builds as part of a server installation. This service now scales horizontally with the rest of the Develocity server, improving availability and supporting larger workloads. The remote build cache node, installed separately, can provide additional redundancy and geographically distributed presence.

Previously, each build cache node, built-in or remote, needed to nominate another node as a replication source when enabling replication between nodes. Now, this is simplified so that any replication-enabled node replicates to and from all other replication-enabled nodes, which always includes the Develocity server’s built-in build cache node. This eases replication configuration, particularly when creating a set of load-balanced remote nodes.

For more information about Build Cache replication, see the Replication section of the Develocity Administration Manual.

The Gradle plugin, Maven extension, and sbt plugin are now based on the “Develocity” product name. This affects plugin IDs, artifact coordinates, configuration DSLs, system properties, and general APIs.

Backwards compatibility with the “Gradle Enterprise” product name has been maintained, with the use of all symbols based on this name having been deprecated.

Please refer to the (Legacy) Gradle Enterprise Gradle Plugin User Manual and (Legacy) Gradle Enterprise Maven Extension User Manual for migration instructions.

The 2024.1 release renames all CI integrations for the new Develocity product name.

For more information, see the release notes for the CI integrations.