Develocity Reporting via Amazon Athena User Manual

A Build Scan® is a persisted record of a single build’s captured data. Each Build Scan consists of thousands to millions of very fine-grained events. Build models aggregate these events into higher-level structures to expose easily consumable, summarized information about the build.

The build models can be exported to Amazon S3 to serve as input to an external big data engine, and they can be consumed via the Develocity API. This guide focuses on exporting the build models to Amazon S3 and their consumption by Amazon Athena.

The build models that are available to DRV are served by the builds endpoint of the Develocity API.

Amazon Athena limits the size of a single row, and of any of its columns, to 32 MB. A very large build can produce a build model that reaches this limit. Develocity 2026.3 stores such a build as more than one row in the build and internal_build tables, numbered by the drv_shard column. Releases before 2026.3 dropped the build instead, so its data never reached Athena.

The summary views and the provided Grafana dashboards account for this, so they need no change. A query of your own against the raw build or internal_build table does need a change, described in Appendix H. === Upgrading From V1.0

For any customers that are currently using Athena V1.0 via the Build Model Export feature and wishing to upgrade, please follow the upgrade instructions in Appendix E

The Athena Data Export process changed twice. Develocity 2025.3 added the synchronized process alongside the original one-off one, and Develocity 2026.1 removed the one-off process together with the athenaDataExport.exportType and athenaDataExport.oneOffExportDatabase settings that chose between them. Those settings only existed to make the transition gradual.

If you are on a release earlier than 2025.3, follow Appendix F to move to the synchronized process, then Appendix G before going to 2026.1 or later.

If you are on 2025.3 or 2025.4 and still set either setting, follow Appendix G, which covers both the upgrade path that keeps reporting data available and the shorter one that does not.

The prerequisites are as follows:

Athena uses Glue to store the table schema. To create a database inside the data catalog, follow the Glue instructions at Working with databases on the AWS Glue console.

This guide assumes the created database is named develocity-db, but you may choose a different name.

Create an Athena workgroup and table to build models from Develocity. You will need the AmazonAthenaFullAccess managed policy to perform these tasks.

The AmazonAthenaFullAccess managed policy covers all the required permissions for any credentials that the Athena Data Export process and related features will make use of.

However in cases where the granted permissions are too broad, the minimal permissions required for the Athena Data Export process are as described below.

The Athena Data Export process requires a schema to be set up in Amazon Athena to make the stored build models queryable. This schema describes the structure of the build models and how they’re stored in S3. Starting from Develocity version 2025.3, Develocity will automatically create and manage all the schema, views and tables required for the Athena Data Export process to function. For more information on this, see Automatic Schema Management. For users that prefer to manage the schema themselves, the steps to take are described in Appendix D.

Run a simple query against the build table to verify that the Athena Data Export process is properly set up and connected to AWS.

In the Query Editor, select the database you created in Glue and issue a simple build model query:

The drv_shard condition counts a very large build one time. See Very Large Builds Span Multiple Rows.

The results are displayed in a table below the Query Editor:

This requires a Grafana instance (on-premises or cloud) with the Athena plugin installed.

Create a Grafana dashboard that displays Develocity build data in a chart. To create a dashboard, follow the Grafana instructions at Create a dashboard.

In step four, select the Grafana data source you previously created from Data source.

The following image shows a bar chart visualization of the number of builds grouped by day using the following query:

See Grafana dashboards for more information.

The dashboard bundle provides a set of pre-defined, JSON-based Develocity dashboard definitions. Importing them is documented in Installing the Dashboard Bundle for Amazon Athena, which covers Grafana and build environment compatibility, the Athena data source prerequisites, and every installation method: Grafana’s built-in provisioning, Helm and Kubernetes provisioning, manual import via the Grafana UI, and Amazon Managed Grafana with Terraform.

Download the bundle from Downloads. Contact your technical contact at Gradle for assistance integrating the dashboards into your on-premises or cloud Grafana instance.

After 2025.3, Develocity will automatically manage the schema required for the Athena Data Export process to function. If you are using the automatic schema management, no action is required to upgrade the Athena tables.

When upgrading Develocity, the schema of the build models may change, and existing views may be updated to include new data to be consumed via the dashboards. This would require updating the Athena tables and views to reflect the new schema.

The automatic schema management will follow the process outlined below to upgrade the tables as needed. All data queried by Athena is stored in external tables or views. Both of these constructs don’t store any data themselves but rather point to the location of the data, that ultimately resides in S3 buckets. This means there is no data loss when dropping the tables or views.

As such, upgrading the Athena tables is a simple process of dropping the tables and views, and re-creating them with the new schema. The same steps as in the initial setup can be followed, but with the updated schema files downloaded from the dashboard bundle.

Upgrading the bundled dashboards is documented in Upgrading in the dashboard bundle component, which covers each Grafana installation type. Upgrading the Athena tables and views is covered in Upgrading Athena Tables above.

To disable the V1.0 Build Model Export via UI, follow these steps:

If the V1.0 Build Model Export was enabled via unattended configuration, you can disable it by updating the following configuration in your unattended configuration file or removing it entirely:

For more information, see the “Unattended configuration” section in the Develocity Administration Manual for Helm Installations.

The dashboard bundle, its contents, and its release history are documented in the Develocity Reporting and Visualization Dashboard Bundle component.

The Amazon Athena variant of the bundle contains the SQL statements that set up the tables and views in Athena, which the dashboards need in order to work.

The Athena Data Export process connects to Amazon Athena over two different ports:

If you are experiencing timeouts or connection issues, check your network configuration to ensure that these ports are open and accessible.

For more details refer to the Amazon Athena documentation.

The V2.0 Athena Data Export and the V1.0 Build Model Export work entirely independently and have different data formats. Existing build model data stored in the V1.0 format cannot be viewed in the V2.0 format. Likewise, data exported in the V2.0 format cannot be viewed in the V1.0 format.

Upgrading from V1.0 requires a complete new setup, so please follow the steps detailed in the Setup guide.

In the 2025.3 release the Athena Data Export process was re-implemented to provide a more robust and scalable solution. This new implementation is used by default when installing or upgrading to 2025.3 or later. The new implementation constantly synchronizes the exported Build Models with Develocity, thus providing a consistent view at all times. This allows us to keep adding new data and not have to rely on re-running the export process manually. In this documentation we will refer to this new engine as "synchronized Athena Data Export" and the old implementation as "one-off Athena Data Export".

Build data exported from Develocity will now be subject to the configured retention period and will be directed to a new location within the designated S3 bucket. It’s important to note that previously exported build data won’t be migrated. Instead, Develocity will initiate a fresh export of all currently retained builds to the new location. This re-export process may be time-consuming and could temporarily strain your Develocity instance until all historical builds have been caught up. Develocity will automatically update the schema definitions of your Glue database to reflect the new S3 location, which will necessitate additional permissions in the attached IAM policy. While this new data export mechanism is the default, Develocity offers configuration options to facilitate a smooth transition. Users have the choice to continue using the existing export method or to configure a second Glue database, allowing the existing export mechanism to run in parallel with the new one until the transition is complete.

Develocity 2026.1 removed the one-off Athena Data Export. The oneOff and both values of athenaDataExport.exportType are no longer accepted, and athenaDataExport.oneOffExportDatabase no longer exists.

Synchronized Athena Data Export is now the only export process. Because exportType has only one remaining value, omit it entirely rather than setting it explicitly.

If either setting is still present in your values.yaml, the Helm chart fails the upgrade instead of silently changing how your build data is exported.

Which upgrade path you take depends on whether you can accept a period without complete reporting data.

Amazon Athena limits the size of a single row, and of any of its columns, to 32 MB. This is a hard limit of the service, and AWS documents it under Considerations and limitations for SQL queries in Amazon Athena. Develocity 2026.3+ stores a build model that reaches this limit as more than one row of the build and internal_build tables, as described in Very Large Builds Span Multiple Rows.

The drv_shard column numbers the rows of one build. The first row is drv_shard = 0, and the rows after it are 1, 2, and so on. Develocity slices the large arrays of the build across these rows, for example the task executions and the artifact transform executions. The other models stay on the first row, so the rows after it hold no value for many columns. A build under the limit is a single row where drv_shard is NULL.

Two rules apply to a query against the raw build and internal_build tables:

The summary views apply both rules for you. The provided Grafana dashboards read the summary views, so a query against build_summary or another summary view needs no change.

In certain situations, you may find that queries made to Athena or the provided dashboards show different numbers than the Develocity UI. Most notably, the Build count metric on the Global Volume dashboard might not match the number of builds shown in Develocity’s scan list page for the same time range.

A few factors can cause this discrepancy:

Amazon Athena enforces rate limits on the number of requests that can be made to the service within a certain time frame. Under high load, it’s possible that Athena throttles requests, resulting in failed queries or delayed data updates with error messages similar to: Could not load query results: software.amazon.awssdk.services.athenastreaming.model.AthenaStreamingException: Rate exceeded

In the unlikely scenario that you encounter such rate limiting issues on a regular basis, consider reaching out to AWS support to request an increase in your Athena service limits for the following APIs:

More details can be found in the Amazon Athena documentation.