Introduction

This manual provides instructions for visualizing Develocity build data by installing the Develocity Reporting Kit into a Kubernetes cluster or onto a standalone host.

If you are looking to visualize Develocity build data in an AWS-hosted setup by using AWS-provided services, you can do that by using AWS S3 and AWS Athena.

The Develocity Reporting Kit (aka the Reporting Kit) is a Kubernetes-based application, distributed as a Helm chart. Helm is a package manager for Kubernetes applications. Helm manages all Develocity Reporting Kit components.

The Reporting Kit is a companion application to a Develocity installation, and is only useful for existing Develocity customers or those trialling Develocity.

Build data

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.

Build models can be consumed via the Develocity API. This guide focuses on installing the Reporting Kit and connecting it to the API of an existing Develocity installation.

Build models are available for only Gradle and Maven builds, currently.
The builds endpoint of the Develocity API serves the build models that are available to the Reporting Kit.

Prerequisites

1. Develocity installation

The Reporting Kit pulls build model data from an existing Develocity installation. To install the Reporting Kit you will need:

The Reporting Kit can visualize Build Scan data pulled from a Develocity instance of version 2023.4 or later. Some of the built-in dashboards rely on data that is available starting with later Develocity versions. Detailed compatibility information is available in the appendix.

2. Build environment

Most of the built-in dashboards rely on the presence of specific tags and custom values on Build Scan data to render the desired visualizations.

Tags used within the dashboards:

  1. CI - Used throughout the dashboards to classify builds as either CI (tag is present) or local (tag is absent) builds

Custom values used within the dashboards:

  1. Git repository - The URI of the Git repository that the build was run in, e.g., git@github.com:gradle/gradle.git

  2. CI provider - The name of the CI provider that ran the build, e.g., GitHub Actions

If you are using the Common Custom User Data Gradle plugin or Common Custom User Data Maven extension, this information will be automatically added to every Build Scan.

Host requirements

This section outlines the requirements for installing the Develocity Reporting Kit.

1. Kubernetes cluster

The Reporting Kit must be installed into a running Kubernetes cluster. The cluster you install the Reporting Kit into needs to have access to sufficient resources. Your cluster should be running a recent version of Kubernetes that is still receiving patch support.

It is also possible to install the Reporting Kit on a single node using the K3s lightweight Kubernetes distribution. Installation instructions are provided below.

We do not recommend installing the Reporting Kit into the same standalone K3s cluster as Develocity, due to competition for resources. See the appendix if you are considering this.

2. Kubernetes platforms

The Develocity Reporting Kit does not use any platform specific features and is expected to work on all platforms, but we have not verified every available platform.

We have verified that the Reporting Kit works on K3s and Amazon EKS.

3. Helm requirements

Check the Helm Version Support Policy to ensure compatibility with your Kubernetes version.

4. Resources

Node group specification

If you are planning to provision a dedicated cluster for your Develocity Reporting Kit installation, our recommended node group specification for that cluster is 2 nodes, each with 4 CPU units and 40 GiB memory.

Resource requests and limits

If you are planning to install the Reporting Kit in an existing cluster, we recommend ensuring access to at least 6 CPU units and 64 GiB memory.

The Develocity Reporting Kit Helm Chart’s total resource requests and limits are:

  • Resource requests (the minimal resources required by the application to start): 3.5 CPU units, 42.07 GiB memory.

  • Resource limits (the maximum resources that might be used by the application if available): 29 CPU units, 66.93 GiB memory.

Single-node installation

If you are planning to install the Develocity Reporting Kit on a single node, then that machine should meet these minimum requirements:

  • 8-core 2GHz or better CPU (amd64 architecture)

  • 64 GB free RAM

5. Storage

The Develocity Reporting Kit uses persistent volume claims for storing data. You can optionally provide the name of the desired storage class to be used for provisioning persistent volumes.

Some Pods are associated with persistent volumes and for Kubernetes platforms with multiple availability zones, the Pods and their persistent volumes must be located in the same zone. In this case it is recommended to use a storage class with a volumeBindingMode of WaitForFirstConsumer to ensure that all persistent volumes are provisioned in the same zone that the Pod was scheduled in.

It is strongly recommended to use storage classes that allow persistent volume claim expansion if available. This makes it straightforward to expand the storage used by the Reporting Kit.

Capacity recommendations

The recommended minimum capacities for the persistent volumes are:

Description Size in GB

MinIO

100

Hive metastore

10

Exact MinIO storage requirements vary greatly depending on the number and size of Build Scans stored in your Develocity instance. We recommend monitoring the available space in your MinIO volume to ensure that your system doesn’t run out of space.

If your storage class does not allow expanding volumes, you should also consider preparing for future data growth by adding additional disk capacity upfront.

Helm configuration

The Develocity Reporting Kit is a Kubernetes-based application, distributed as a Helm chart. Helm is a package manager for Kubernetes applications, and it manages all Develocity Reporting Kit components. A Helm chart is a Kubernetes manifest template, with variables that can be provided at installation time.

Providing configuration to Helm

Helm uses a values.yaml file to populate these variables and generate the Kubernetes manifests.

The variables in values.yaml configure the Develocity installation with information such as networking, database, or hostname settings.

Here is a minimal sample values.yaml file for installing the Develocity Reporting Kit:

values.yaml 
develocity:
  address: https://develocity.example.com
  accessKey: "aecitwnpfw7h2sp3bl5uhrk5yedk47756obrsmneevvfe6jo2ssa"

Helm configuration can be provided in several ways:

  • Creating a Helm values file and passing it to helm using --values.

  • Passing values directly to the helm command using --set or --set-file.

  • Editing the default Helm values file in the chart before running helm.

We generally recommend setting values in a values.yaml file, because it means that your configuration is all in one place, and you have a more straightforward command to run for installation and upgrades.

Once your values.yaml file is complete, you will install the Reporting Kit using a command similar to the one below:

helm install --values ./values.yaml
Unless otherwise indicated, most values are optional and have usable defaults.

User-managed secrets

The Develocity Reporting Kit allows you to configure several secret values for various purposes described below. The Reporting Kit’s Helm chart allows you to set secret values directly in Helm configuration. In this case, Helm will create the Kubernetes Secret which contains the secret value. As an alternative, it is usually possible in the Reporting Kit’s Helm chart to set the secret value in a Kubernetes Secret that you create and manage independently of Helm. If you use such a user-managed secret, you need to provide Helm with the name of the secret you have created for that purpose.

For example, if you want to configure the Grafana editor password using a user-managed secret, then you would create a secret (for example, using kubectl), take a note of the name, and then add it to your Helm values file using a prescribed Helm value.
For different secret values which the Reporting Kit’s Helm chart allows to be configured using a user-managed secret, you will need to use a different, specific Helm value, typically of the form some.thing.secretName. In this example, for the Grafana admin password, the Helm value to use is grafana.editorAccount.secretName. Wherever a user-managed secret can be used to configure a secret value, the data items that the secret needs to contain will be mentioned in the same place where the configuration of that secret value is documented.

Here is a sample values.yaml file for installing the Develocity Reporting Kit:

values.yaml 
# Target Develocity server
develocity:
  address: https://develocity.example.com
  accessKey: "aecitwnpfw7h2sp3bl5uhrk5yedk47756obrsmneevvfe6jo2ssa"

# Optionally create an editor account capable of creating custom dashboards
grafana:
  editorAccount:
    username: "editor"
    password: "showmethedata1234"

# Set the MinIO storage capacity a bit higher than the default
minio:
  storage:
    capacity: 200Gi

Deterministic Helm template output

If you use tools that redeploy applications based on changes in the output of helm template, such as ArgoCD, then you may need to ensure that the output of helm template is deterministic based on the Helm values you provide. To achieve this, read the appendix of this manual covering deterministic Helm output.

Helm options

Each section below contains an overview of Develocity Reporting Kit installation options and their corresponding values.yaml variables:

  1. Global options (license, images, annotations, storage class, security context, trusted certificates)

  2. Develocity configuration

  3. Pod resources

  4. Access control

  5. Ingress configuration

  6. Scaling

  7. Query results cache

1. Global options

Configuration for pulling images into the installation cluster

In order to pull images from the Gradle registry at https://registry.gradle.com/, you need to provide your Develocity license file to Helm at installation time when installing the Reporting Kit. This is the same license file as the one used for your Develocity installation. The easiest way to do this is to pass --set-file global.license.file=/path/to/develocity.license as an argument when running helm install.

You can also provide the license file inline in the values file. Only the "data" portion of the license is needed in the Helm value file, but it is acceptable to include the entire license file contents:

values.yaml 
global:
  license:
    file: R0VMRgF4nBWOSZKCMAAAX+QUu3BUIJAIwUQiwsViEwMIDKOyvH701n3p6nJBYxoRHnAUnwHwKLjb...

It is also possible to specify the imagePullSecret using a user-managed secret.

Using a user-managed secret for pulling images

To manually create a secret containing the Develocity license within the same namespace as the Develocity Reporting Kit, follow these steps:

Create a namespace for the Develocity Reporting Kit, if it does not already exist:

$ kubectl create namespace develocity-reporting-kit (1)
1 This example uses develocity-reporting-kit as the namespace, but it can be a custom name. If you use a custom name, update following commands accordingly.

Create a docker-registry secret with the Develocity license:

$ kubectl -n develocity-reporting-kit create secret docker-registry my-develocity-license-image-pull-secret \(1)
    --docker-username=develocity \
    "--docker-password=$(cat path/to/develocity.license)" \
    --docker-server=registry.gradle.com
1 my-develocity-license-image-pull-secret is the name of the secret. It can be any name you choose.

In your values.yaml file, be sure to include the name of the specific secret you want to use within the imagePullSecret key:

values.yaml 
global:
  image:
    imagePullSecret: my-develocity-license-image-pull-secret
Airgap installation image pull policy

In a K3s-based airgap installation onto a standalone host, Helm should be configured so that no attempt is made to pull images from the outside world with the values below:

values.yaml 
global:
  image:
    imagePullPolicy: Never

This is because in a K3s-based standalone airgap installation, you import images onto the K3s node directly, rather than pulling them from a registry.

StorageClass

The same StorageClass is used for all persistent volume claims. It can be configured by setting the Helm value global.storage.data.class.

Pod annotations

Pod annotations for all Pods can be configured by setting the Helm value global.podAnnotations.

Security context

By default, all Pods are created with a security context defining a non-root user for the containers to run as. This is our most tested configuration, and it is secure, so you should leave this enabled if you can. In some environments, most notably in OpenShift clusters, these may need to be disabled for the application to run correctly. This can be done by setting the Helm value global.securityContext.enabled to false.

Trusted TLS certificates

By default, the Develocity Reporting Kit uses the default trust settings of the Java runtime that it ships with when connecting to other systems using TLS. If you use an internal Certificate Authority (CA), you may need to provide additional TLS certificates for the Reporting Kit to trust. You only need to add additional TLS certificates if these are necessary to connect to Develocity.

To specify custom trusted TLS certificates for the Reporting Kit, set the Helm value global.network.additionalTrust to the contents of a file containing X509 certificates in PEM format, newline separated if there are more than one. An example is shown below:

values.yaml 
global:
  network:
    additionalTrust: |
      -----BEGIN CERTIFICATE-----
      MIIDlzCCAn+gAwIBAgIUS098FlRZcuXLeXBhnf40E9WjtWQwDQYJKoZIhvcNAQEL
      ...
      +W892fTw2irGwfg=
      -----END CERTIFICATE-----
      -----BEGIN CERTIFICATE-----
      MIIDfzCCAmegAwIBAgIURqPslYGu7cHXs22q3RK6e5L87PwwDQYJKoZIhvcNAQEL
      ...
      s10yB5VjVBES6A22rYwYb8mImpQiVP/mr4ao5U5m+h50l3E=
      -----END CERTIFICATE-----

Alternatively, you can set this value by passing the argument --set-file global.network.additionalTrust=/path/to/trusted-certificates.pem when running helm install.

2. Develocity configuration

The Develocity Reporting Kit requires an authorized connection to a Develocity instance in order to pull builds. This connection can be configured by setting the values develocity.accessKey and develocity.address.

If you’d prefer to manage the access key secret yourself, you can do so by setting develocity.accessKey.secretName instead of develocity.accessKey. The secret named by this value should contain a single item of data, accessKey, which should be set to a base64 encoded Develocity access key that has the correct Develocity permissions.

Develocity access key

The Reporting Kit must be configured with an access key associated with an account that has the Access build data via the API permission. This permission is exportData in a Develocity unattended config file.

See the Admin Manual for more details on access control and permissions, and the API User Manual for more on access key provision and verifying user granted permissions.

Build data

By default, the Reporting Kit will pull the previous 30 days of data from your Develocity instance. This can be configured by setting the Helm value buildData.days to a positive integer number of days.

The buildData.days Helm value is not a retention period. Currently, the only way to limit the amount of data that the Reporting Kit pulls from Develocity is to scale down the data-synchronizer deployment to 0 replicas. This will prevent any additional data from being pulled. To scale the data-synchronizer down, run the following command:

kubectl -n develocity-reporting-kit scale deploy data-synchronizer --replicas=0

3. Pod resources

Memory and CPU

The resource requests and limits for each container of each Pod can be controlled using Helm values. Init containers, where they are present, use the same resource requests and limits from an appropriate non-init container. The pattern for configuring these resources is to use the Helm values <prefix>.resources.limits.cpu, <prefix>.resources.limits.memory, <prefix>.resources.requests.cpu, <prefix>.resources.requests.memory, where <prefix> is any of:

  • dataSynchronizer

  • grafana.main

  • grafana.accountInitializer

  • hiveMetastore.main

  • hiveMetastore.postgres

  • minio

  • trino.coordinator

  • trino.worker

  • trino.cache

Storage

  • minio.storage.capacity configures the amount of storage available to MinIO for storing Build Scan data.

  • hiveMetastore.storage.capacity configures the amount of storage available for storing partition metadata by the hive metastore. We don’t expect this to be very large ordinarily, so you should use the default value unless directed to change it by a member of the Gradle support team.

  • grafana.storage.capacity configures the amount of storage available to the Grafana’s embedded database. We don’t expect this to be very large ordinarily, so you should use the default value unless directed to change it by a member of the Gradle support team.

These values need to be provided in the format of a Kubernetes storage size.

Ephemeral storage

Ephemeral container storage is used by Trino workers for their file cache when processing SQL queries.

We recommend that you change these values only if instructed to do so by a member of the Gradle support team.

  • trino.worker.resources.limits.cacheSize configures the size of the file cache used by Trino query workers for processing SQL queries. When increasing this value, you must also correspondingly increase the values trino.worker.resources.requests.ephemeralStorage and trino.worker.resources.limits.ephemeralStorage, to prevent pod scheduling issues.

  • trino.worker.resources.requests.ephemeralStorage configures the minimum amount of ephemeral container storage required in order for Trino worker containers to be scheduled.

  • trino.worker.resources.requests.ephemeralStorage configures the maximum amount of ephemeral container storage Trino worker containers can consume.

4. Access control

A few components in the Develocity Reporting Kit use credentials, and these can be configured using Helm values.

Grafana

The frontend of the Reporting Kit is an embedded Grafana service, which displays the visualizations of the build data. By default, this can be viewed anonymously and without authentication.

If you want to disable anonymous access to view the dashboards, set grafana.anonymousAccess to false. This will mean that all access must use the editor account.

Grafana editor account

The Reporting Kit supports optionally creating a single, shared editor account. In addition to viewing the bundled dashboards, this account can also create new dashboards for custom visualizations. To create an editor account, set grafana.editorAccount.username and grafana.editorAccount.password.

You can also instead configure the editor user’s username and password using a user-managed secret. Set grafana.editorAccount.secretName to point to the secret, which must have two data items, user and password.

Grafana admin account

The admin account for the Reporting Kit’s embedded Grafana instance always has the username admin. You can configure the password for the admin account by setting the Helm value grafana.adminAccount.password. You can also use a user-managed secret, by setting grafana.adminAccount.secretName to the name of a secret containing a single data item, password.

5. Ingress configuration

By default, the Develocity Reporting Kit Helm chart will create a Kubernetes Ingress to serve inbound traffic to the app. If you want to disable the default Ingress in order to use some other routing solution provided by your cluster, set ingress.enabled to false. The Ingress created by the Helm chart will in this subsection be referred to as the Helm-managed Ingress.

Hostname

By default, the Helm-managed Ingress is not restricted to a single hostname, and will attempt to route traffic for all hosts to the Reporting Kit. If deploying in a cluster with other applications installed, you can set ingress.hostname to only route traffic for a single host through to the Reporting Kit.

Customizations

You can provide additional Kubernetes resource annotations to be set on the created Ingress. This is done by setting key-value pairs under the Helm value ingress.annotations, in the same way as is described for Ingress annotations in the Develocity Helm Chart Configuration Guide.

By default, the created Ingress will use the default Kubernetes Ingress class provided by the Kubernetes cluster. If you want to override this to use a specific, fixed Ingress class, then set the Helm value ingress.ingressClassName to the name of the Ingress class you’d like to use.

The default pathType for the created Kubernetes Ingress is Prefix. If you need to instead use the path matching implementation provided by the Ingress class, then set the Helm value ingress.pathType to ImplementationSpecific.

TLS

By default, the Helm-managed Ingress will use plain HTTP only.

To enable HTTPS support, set ingress.ssl.enabled to true and provide a hostname for your installation by setting the Helm value ingress.hostname. By default, if HTTPS support is enabled, the Helm chart will generate and use self-signed SSL certificates. If instead you want to provide custom SSL certificates, for example ones signed by your own internal Certificate Authority, then you can do so by providing the SSL certificate and SSL key as Helm values. This can be done by passing --set-file ingress.ssl.key=/path/to/key/file --set-file ingress.ssl.cert=/path/to/cert/file to Helm when running the installation command, or by providing them inline in the values file as shown below:

values.yaml 
ingress:
  ssl:
    enabled: true
    cert: |
      -----BEGIN CERTIFICATE-----
      MIIDKjCCAhKgAwIBAgIRAPNTIHf6/oUuzMKm3ffGNOgwDQYJKoZIhvcNAQELBQAw
      HDEaMBgGA1UEAxMRYXV0by1nZW5lcmF0ZWQtY2EwHhcNMjExMTMwMTU1NDU5WhcN
      ...
      Cn/3yUirFVTslrSYKAemLw8btLO6FDF9dc/lq1o7tKsYVuhEcjqnTah7puJjEN9h
      z+P5RmRxU/kaaFB+Vuw1pRezbaAtZNorVgXnBwrdseY4zLGyhAcGcR9v+VtCiQ==
      -----END CERTIFICATE-----
    key: |
      -----BEGIN RSA PRIVATE KEY-----
      MIIEpQIBAAKCAQEA4qV8JlqDMi7y85Ykq8dn7uIsi609D6KuFtlc+UvNYjatz0+u
      QzIr3iw//qf7sM8nx8fhGwuWvUWeCE6zbgKjuxDH82J9NQ0ctf70n0qVTeyW1CKR
      ...
      XlOfXr/xvkXA66PROgvVxfwpN/GNrLXFi1HvMg7MVZJUZQpNzpAzw5JTk2MbawOl
      G7tI0qQ6F20e5R4tPpEDKCFZykyvgGMhfLzsvVlrgaVW8QbVK4YWNtQ=
      -----END RSA PRIVATE KEY-----

You can also use a user-managed secret for the SSL key and certificate. This secret should be a Kubernetes TLS Secret, and the name of the secret needs to be provided in the Helm value ingress.ssl.secretName.

6. Scaling

The number of Trino workers used to process SQL queries can be configured using the Helm value trino.worker.replicas. For most installations we recommend using the default value, 1.

7. Query results cache

See Query result caching for more details about the query results cache.

  • trino.cache.defaultRetention configures the duration for which query results will be cached. A value of 0 disables the cache. The default is 1d.

  • trino.cache.purgeInterval configures the frequency with which expired cache entries will be removed from the file system. It defaults to 1d.

8. Trino

There are Helm values for configuring details of the embedded Trino query engine included with the Reporting Kit, however you should not adjust the defaults, unless advised to do so by Gradle support.

  • trino.maxHttpContentLength configures a maximum content length for data transferred within the cluster while processing queries. You only need to adjust this if you notice dashboards failing with an error such as error querying the database: Remote page is too large. The default value is 64MB.

Installation

In this section you will install the Develocity Reporting Kit on your host or cluster.

To install the Reporting Kit, commands will need to be executed on the installation host or on a host with connectivity to your Kubernetes cluster and to the internet.

1. Install K3s (If applicable)

If installing on a host rather than an existing cluster, first install K3s and make it available to the current user:

$ curl -sfL https://get.k3s.io | sh -
$ sudo chown $UID /etc/rancher/k3s/k3s.yaml
$ mkdir -p "${HOME}/.kube"
$ ln -sf /etc/rancher/k3s/k3s.yaml "${HOME}/.kube/config"

Verify that you can interact with the K3s cluster:

$ kubectl get namespace

The expected output should be similar to this:

Output 
NAME                STATUS   AGE
default             Active   1h
kube-system         Active   1h
kube-public         Active   1h
kube-node-lease     Active   1h
For more information on K3s installation, see the K3s Quick-Start Guide and K3s Installation.

2. Install Helm

The Develocity Reporting Kit requires Helm version 3.5.x (or later) to install.

It is recommended to use the latest version available as this will have all known security vulnerabilities addressed. This document describes the maximum version skew supported between Helm and Kubernetes.

For more information on installing Helm (including alternate installation approaches), see Installing Helm.

Install Helm with the following command:

$ curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

3. Tell Helm about the Gradle Helm repository

The Develocity Reporting Kit is distributed from the Gradle Helm repository.

Add the Gradle Helm repository to your Helm installation and fetch its contents into the local cache:

$ helm repo add gradle https://helm.gradle.com/
$ helm repo update gradle

Verify that the Develocity Reporting Kit chart is accessible:

$ helm search repo develocity-reporting-kit

This will report the latest versions available for the two Develocity charts:

Output 
NAME                           	 CHART VERSION	APP VERSION	 DESCRIPTION
gradle/develocity-reporting-kit	 1.2.0          1.2          Official Develocity Reporting Kit

3. Install the Develocity Reporting Kit

Install the Develocity Reporting Kit:

$ helm install \
    --create-namespace --namespace develocity-reporting-kit \(1)
    develocity-reporting-kit \(2)
    gradle/develocity-reporting-kit \(3)
    --values values.yaml \(4)
    --set-file global.license.file=./develocity.license (5)
1 This example uses develocity-reporting-kit as the namespace, but it can be a custom name. If you use a custom name, update all other example commands accordingly. Running with --create-namespace will create the namespace if it does not already exist.
The namespace option may not be required for OpenShift if oc login has been run and the active project for the current context is set.
2 This is the Helm release name. It is used by Helm to identify the Develocity Reporting Kit installation.
3 The Helm chart to install. To install a specific version, use e.g. --version 1.2.0.
4 The Helm values file containing configuration values as described above.
5 The Develocity license file (if not already included in your values file).

4. Confirm that the Develocity Reporting Kit is running

At this point, it should be possible to see the Helm release installed:

$ helm --namespace develocity-reporting-kit list
Output 
NAME                    	NAMESPACE               	REVISION	UPDATED                             	STATUS  	CHART                           APP VERSION
develocity-reporting-kit	develocity-reporting-kit	1       	2024-04-05 16:20:07.618596 +0800 +08	deployed	develocity-reporting-kit-1.2.0	1.2

You can inspect the status of the Develocity Pods:

$ kubectl --namespace develocity-reporting-kit get pods
Output 
NAME                                 READY   STATUS              RESTARTS   AGE
grafana-5bd84f6bff-jhl8v             0/2     ContainerCreating   0          12s
trino-worker-79f8ddfdd8-k6fc6        0/1     Init:0/1            0          12s
trino-coordinator-7d8794689-jrqn6    0/1     Init:0/1            0          12s
data-synchronizer-8489cd7749-gxv8h   0/1     Init:0/2            0          12s
minio-7b9d87c4c7-tsqss               0/1     ContainerCreating   0          12s
hive-metastore-7bfc5977b8-vwzkf      0/2     ContainerCreating   0          12s
Sometimes containers will initially fail when they start up because other Pods they depend on are not ready yet. This is normal and expected. In Kubernetes applications, it is idiomatic for containers to repeatedly attempt to start, crash, and be restarted by the Kubelet until their dependencies are ready, because this prevents wasted allocation of requested resources while dependencies are starting up.

Within several minutes all the Pods should have the status Running:

Output 
NAME                                 READY   STATUS    RESTARTS        AGE
minio-7b9d87c4c7-tsqss               1/1     Running   0               8m10s
grafana-5bd84f6bff-jhl8v             2/2     Running   0               8m10s
hive-metastore-7bfc5977b8-vwzkf      2/2     Running   2 (6m23s ago)   8m10s
trino-worker-79f8ddfdd8-k6fc6        1/1     Running   0               8m10s
trino-coordinator-7d8794689-jrqn6    1/1     Running   0               8m10s
data-synchronizer-8489cd7749-gxv8h   1/1     Running   0               8m10s

The Develocity Reporting Kit has a /ping endpoint, which you use to verify that the application is accessible from your computer.

Connectivity to the Develocity Reporting Kit installation can be tested by running the following command on machines which need to connect to it:

$ curl -sw \\n --fail-with-body --show-error «develocity-reporting-kit-origin»/ping

This should show the text SUCCESS.

Once all Pods have a status of Running and the system is up and connected, you can interact with the Develocity Reporting Kit instance by visiting its address in a web browser. The root path of the Reporting Kit application is currently a generic Grafana landing page. If you navigate to the /dashboards path, you should be able to see a list of dashboard folders containing different dashboards for you to explore.

dashboards

Within 10 minutes of the instance being up and running, data from your Develocity instance should have started to get synced to your Reporting Kit instance, which you will be able to see in the dashboards.

global volume

At this point, the Develocity Reporting Kit instance is installed and running.

Check the troubleshooting section if your dashboard does not display data within 15 minutes.

Airgap Installation

In an airgap installation, the container images can either be pulled from an image registry available on an internal network that is accessible from the cluster, or, if you are installing the Reporting Kit on K3s, they can be loaded directly into the Kubernetes node, meaning that they do not need to be pulled from a registry.

Airgap installations require a specific entitlement on your license. Please contact Gradle if you need an Airgap-enabled license.

Airgap installation involves downloading files, transferring them, installing supporting software, and running helm install.

We recommend you save all the files into a single transfer directory, so that it is easy to transfer to the host where you are installing the Develocity Reporting Kit. For example:

$ mkdir develocity-reporting-kit-files && cd develocity-reporting-kit-files

1. Download the required files

a. Download K3s (If applicable)

If installing onto a standalone host using K3s, you need to also install K3s on your airgapped installation host. Otherwise, this step can be skipped.

Please make note of the checksums provided in the k3s release page. The checksums can be found under Assets/sha256sum-amd64.txt for the release that you are planning to use.

To get the name of the release, please execute the following command:

$ curl -s https://api.github.com/repos/k3s-io/k3s/releases/latest | jq -r '.tag_name'

Then you can download and verify the K3s images, binary, and install script:

$ curl -LO https://github.com/k3s-io/k3s/releases/latest/download/k3s
$ curl -LO https://github.com/k3s-io/k3s/releases/latest/download/k3s-airgap-images-amd64.tar.gz
$ curl -L -o install_k3s.sh https://get.k3s.io
$ echo "<sha 256 checksum of 'k3s'> k3s" | sha256sum -c
$ echo "<sha 256 checksum of 'k3s-airgap-images-amd64.tar.gz'>  k3s-airgap-images-amd64.tar.gz" | sha256sum -c

If you are running Red Hat Enterprise Linux with SELinux enabled, you will also need to download and verify the K3s SELinux Policy package:

$ curl -L -o k3s-selinux.el8.noarch.rpm https://github.com/k3s-io/k3s-selinux/releases/download/v1.2.stable.2/k3s-selinux-1.2-2.el8.noarch.rpm
$ echo "e949fde3e0255c6b5ce3f52db4277897882ed1664e87bfcf5122df5e96559340  k3s-selinux.el8.noarch.rpm" | sha256sum -c

b. Download Helm

Download and verify the Helm binary:

$ curl -L -o helm-linux-amd64.tar.gz https://get.helm.sh/helm-v3.15.4-linux-amd64.tar.gz
$ echo "bbb6e7c6201458b235f335280f35493950dcd856825ddcfd1d3b40ae757d5c7d  helm-linux-amd64.tar.gz" | sha256sum -c

c. Download the installation bundle

Save your Develocity license to the transfer directory as develocity.license.

Download and verify the airgap bundle:

$ curl -LOJd @develocity.license https://registry.gradle.com/airgap/develocity-reporting-kit-1.2-bundle.tar.gz
$ curl -LOJd @develocity.license https://registry.gradle.com/airgap/develocity-reporting-kit-1.2-bundle.tar.gz.sha256
$ sha256sum -c develocity-reporting-kit-1.2-bundle.tar.gz.sha256

If checksum verification fails, check the contents of the downloaded files for error messages. If the error message indicates that your license is invalid/expired/not airgap enabled, you will need to request an updated license file by contacting your customer success representative.

Instead of running the above curl commands, you can download the airgap bundle by navigating to https://registry.gradle.com/airgap/develocity-reporting-kit in your browser and following the instructions on the page.

2. Prepare a Helm values file

Follow the instructions at Helm Configuration and return to this point with a complete values.yaml file.

If you are installing onto a standalone host using K3s, ensure your values.yaml file includes appropriate configuration for the image pull policy.

Before transferring files to the host where you will install the Develocity Reporting Kit, move your Helm values file into the transfer directory.

3. Transfer files

Check that the transfer directory contains all of the following files (additional files are fine):

  • helm-linux-amd64.tar.gz

  • develocity.license

  • values.yaml

  • develocity-reporting-kit-1.2-bundle.tar.gz

  • Optional: SSL certificates

If you are installing on a standalone host, check that the following files are also there:

  • k3s-airgap-images-amd64.tar.gz

  • k3s

  • install_k3s.sh

  • k3s-selinux.el8.noarch.rpm (only if your installation host is using SELinux)

Once you’ve verified that you have the required files, transfer them to the host where you are installing the Reporting Kit.

4. Install K3s (If applicable)

Only do this step if you are installing the Develocity Reporting Kit onto a standalone host using K3s.

Follow these instructions on the host where you are installing the Reporting Kit with your transferred files present in the current directory.

  1. If you are running Red Hat Enterprise Linux with SELinux enabled:

    1. Install the container-selinux package. This is a package that can be found in Red Hat Enterprise Linux’s default repository. Install this package on the airgapped server just like you would install any other package. If your organization has an internal mirror of the Red Hat package repositories, you can run:

      $ sudo yum install -y container-selinux

    2. Install the K3s SELinux Policy package:

      $ sudo yum install -y k3s-selinux.el8.noarch.rpm

  2. Install K3s and make it available to the current user:

    $ sudo mkdir -p /var/lib/rancher/k3s/agent/images/
    $ sudo cp k3s-airgap-images-amd64.tar.gz /var/lib/rancher/k3s/agent/images/
    $ (cd /var/lib/rancher/k3s/agent/images/ && sudo gunzip -f k3s-airgap-images-amd64.tar.gz)
    $ sudo cp k3s /usr/local/bin
    $ sudo chmod a+rx /usr/local/bin/k3s
    $ sudo chmod a+rx ./install_k3s.sh
    $ INSTALL_K3S_SKIP_DOWNLOAD=true ./install_k3s.sh
    $ sudo chown $UID /etc/rancher/k3s/k3s.yaml
    $ mkdir -p "${HOME}/.kube"
    $ ln -sf /etc/rancher/k3s/k3s.yaml "${HOME}/.kube/config"

  3. Verify that you can interact with the K3s cluster:

    $ kubectl get namespace

    The output should be similar to this:

    Output 
    NAME                STATUS   AGE
default             Active   1h
kube-system         Active   1h
kube-public         Active   1h
kube-node-lease     Active   1h

5. Install Helm

Follow these instructions on the host where you are installing the Reporting Kit with your transferred files present in the current directory.

To install Helm:

$ tar -zxvf helm-linux-amd64.tar.gz
$ sudo mv linux-amd64/helm /usr/local/bin/helm

6. Install the Develocity Reporting Kit

Follow these instructions on the host where you are installing the Reporting Kit with your transferred files present in the current directory.

Expand the bundle:

$ tar zxvf develocity-reporting-kit-1.2-bundle.tar.gz

Import Develocity Reporting Kit images

If you are installing the Reporting Kit onto a standalone host with K3s, import the images into K3s using the following command:

$ sudo k3s ctr images import develocity-reporting-kit-1.2-images.tar

Otherwise, upload the images to your internal image registry:

You must be logged in to the registry prior to running these commands. 
$ ./upload-images.sh --registry=registry.example.com/develocity-reporting-kit

Install the Develocity Reporting Kit Helm chart in airgap mode

Install the Develocity Reporting Kit using Helm:

$ helm install \
    --create-namespace --namespace develocity-reporting-kit \(1)
    develocity-reporting-kit \(2)
    develocity-reporting-kit-1.2.0.tgz \
    --values values.yaml \(3)
    --set-file global.license.file=./develocity.license(4)
1 This example uses develocity-reporting-kit as the namespace, but it can be a custom name. If you use a custom name, update all other example commands accordingly.
2 This is the Helm release name. It is used by Helm to identify the Reporting Kit installation.
3 The Helm values file with configuration values, including items such as the Develocity address.
4 The Develocity license file (if not already included in the values file).

7. Confirm that the Develocity Reporting Kit is running

At this point, it should be possible to see the Helm release installed:

$ helm --namespace develocity-reporting-kit list
Output 
NAME                    	NAMESPACE               	REVISION	UPDATED                             	STATUS  	CHART                           APP VERSION
develocity-reporting-kit	develocity-reporting-kit	1       	2024-04-05 16:20:07.618596 +0800 +08	deployed	develocity-reporting-kit-1.2.0	1.2

You can inspect the status of the Develocity Pods:

$ kubectl --namespace develocity-reporting-kit get pods
Output 
NAME                                 READY   STATUS              RESTARTS   AGE
grafana-5bd84f6bff-jhl8v             0/2     ContainerCreating   0          12s
trino-worker-79f8ddfdd8-k6fc6        0/1     Init:0/1            0          12s
trino-coordinator-7d8794689-jrqn6    0/1     Init:0/1            0          12s
data-synchronizer-8489cd7749-gxv8h   0/1     Init:0/2            0          12s
minio-7b9d87c4c7-tsqss               0/1     ContainerCreating   0          12s
hive-metastore-7bfc5977b8-vwzkf      0/2     ContainerCreating   0          12s
Sometimes containers will initially fail when they start up because other Pods they depend on are not ready yet. This is normal and expected. In Kubernetes applications, it is idiomatic for containers to repeatedly attempt to start, crash, and be restarted by the Kubelet until their dependencies are ready, because this prevents wasted allocation of requested resources while dependencies are starting up.

Within several minutes all the Pods should have the status Running:

Output 
NAME                                 READY   STATUS    RESTARTS        AGE
minio-7b9d87c4c7-tsqss               1/1     Running   0               8m10s
grafana-5bd84f6bff-jhl8v             2/2     Running   0               8m10s
hive-metastore-7bfc5977b8-vwzkf      2/2     Running   2 (6m23s ago)   8m10s
trino-worker-79f8ddfdd8-k6fc6        1/1     Running   0               8m10s
trino-coordinator-7d8794689-jrqn6    1/1     Running   0               8m10s
data-synchronizer-8489cd7749-gxv8h   1/1     Running   0               8m10s

The Develocity Reporting Kit has a /ping endpoint, which you use to verify that the application is accessible from your computer.

Connectivity to the Develocity Reporting Kit installation can be tested by running the following command on machines which need to connect to it:

$ curl -sw \\n --fail-with-body --show-error «develocity-reporting-kit-origin»/ping

This should show the text SUCCESS.

Once all Pods have a status of Running and the system is up and connected, you can interact with the Develocity Reporting Kit instance by visiting its address in a web browser. The root path of the Reporting Kit application is currently a generic Grafana landing page. If you navigate to the /dashboards path, you should be able to see a list of dashboard folders containing different dashboards for you to explore.

dashboards

Within 10 minutes of the instance being up and running, data from your Develocity instance should have started to get synced to your Reporting Kit instance, which you will be able to see in the dashboards.

global volume

At this point, the Develocity Reporting Kit instance is installed and running.

Check the troubleshooting section if your dashboard does not display data within 15 minutes.

Post-installation

Once the Develocity Reporting Kit has been installed, files used during installation are not required at runtime and can be removed if desired. However, the following files may be useful to preserve, as they may aid in future upgrades or maintenance:

  • Helm values files

  • SSL certificates

  • Develocity license

These files contain sensitive information and should be handled with care.

Upgrading

Before upgrading, check the release notes for any special considerations when upgrading from older versions of the Develocity Reporting Kit.

Any new or updated Helm config values you specify will be merged with previous Helm config values when you run the helm upgrade command.

To force helm upgrade to use only the values that you set at upgrade time, run with --reset-values instead of --reuse-values.

Running helm upgrade with --reset-values will cause any previous values to be lost. All values (including license files, SSL certificates, etc.) will need to be set as part of the command.

If using helm template, all values must be supplied for each invocation, including any files, as if you had used --reset-values.

Online

1. Upgrade Helm

Identify the latest Helm versions supported by the version of Develocity Reporting Kit you are upgrading to using the compatibility matrix.

Then upgrade Helm:

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh -v «helm-version»

2. Upgrade the Develocity Reporting Kit

To upgrade Develocity Reporting Kit:

  1. To update locally available charts, run:

    helm repo update gradle

  2. Run the upgrade command:

    $ helm upgrade \
    --namespace develocity-reporting-kit \
    --reuse-values \(1)
    develocity-reporting-kit gradle/{chartName} (2)
1 The --reuse-values parameter instructs Helm to reuse previous values.
2 Use the Helm release name you used during installation (develocity-reporting-kit in the examples in this guide).

Airgap

Upgrading an airgap instance of Develocity Reporting Kit requires downloading the updates, transferring them to a machine with access to the Kubernetes cluster and container registry, and then installing them.

You can follow the steps outlined in the Airgap Installation to run the required preparation steps.

Upgrade the Develocity Reporting Kit

Then upgrade Develocity Reporting Kit:

$ tar zxvf {chartName}-«chart-version»-bundle.tar.gz (1)
1 Unpacks the airgap bundle. You may have already done this, in which case you can skip this command. 
$ helm upgrade \
    --namespace develocity-reporting-kit \
    --reuse-values \(1)
    develocity-reporting-kit {chartName}-«chart-version».tgz (2)
1 The --reuse-values parameter instructs Helm to reuse previous values.
2 Use the Helm release name you used during installation (develocity-reporting-kit in the examples in this guide).

Changing configuration values

To change configuration values, follow the same procedure as for upgrading, but specify the current version to ensure that you do not accidentally install a later version.

It is important to specify the currently installed version, because if you don’t, you may accidentally install a newer version and initiate an upgrade rather than merely a configuration change. Such accidental upgrades may be irreversible.

To check the currently deployed version, run:

$ helm history --namespace develocity-reporting-kit develocity-reporting-kit --max 1

To apply new configuration values to a Helm-managed online installation, run:

$ helm upgrade \
    --namespace develocity-reporting-kit \
    develocity-reporting-kit gradle/{chartName} \
    --version «deployed-version» \
    --reuse-values \
    «new values options»

or for a Helm-managed airgap installation:

$ helm upgrade \
    --namespace develocity-reporting-kit \
    develocity-reporting-kit {chartName}-«deployed-version».tgz \
    --version «deployed-version» \
    --reuse-values \
    «new values options»
Since you are using the same version of Develocity Reporting Kit, you should already have the {chartName}-«deployed-version».tgz Helm chart file on the host. If not, you can obtain it by following this step of the installation guide.
Ensure the chart file’s version matches the version of the installed Develocity Reporting Kit instance. If you use a different version, Develocity Reporting Kit’s images may not be present on the host, and Develocity Reporting Kit will not start. To use a later version of Develocity Reporting Kit, follow the upgrade instructions earlier in this guide.

Where «deployed-version» is the running version of Develocity Reporting Kit. The above examples reuse previous values by default. Any specified values will override the existing values. Alternatively, if you want to specify all values explicitly (ignoring any previously set values), run with --reset-values instead of --reuse-values.

Running helm upgrade with --reset-values will cause any previous values to be lost. All values (including license files, SSL certificates, etc.) will need to be set as part of the command.

Configuration values are provided to Helm when running the helm command by:

  • Providing a Helm values file (which can contain inline files) with --values

  • Providing files (such as the Develocity license or certificates) with --set-file

If you have made local modifications to a Helm values file, apply the changes to your installation by running an upgrade command (see above) with a --values «updated-values-file» option.

If you have made local modifications to a file you previously provided via --set-file, apply the changes to running an upgrade command (see above) with a --set-file option.

FAQ

This section provides answers to frequently asked questions and some guidance on troubleshooting your Develocity Reporting Kit deployment.

Installation

This section addresses common questions and issues related to the installation of the Develocity Reporting Kit.

Can I install Develocity and the Reporting Kit into the same namespace?

Answer

Yes, installing the Reporting Kit into the same Kubernetes namespace as Develocity is possible. However, we advise against it if possible due to resource competition between the applications.
For more information, refer to installing it into the same Kubernetes namespace as Develocity.

If you have any questions, contact the Develocity support team by creating a support ticket.

Empty Dashboards

This section provides guidance for troubleshooting common issues with empty Grafana dashboards.

When the Reporting Kit is started for the first time, the data-synchronizer Pod begins pulling build data from the configured Develocity instance.

However, builds that have been pulled and saved to MinIO are not immediately visible to Grafana queries; it can take several minutes for the data to appear in the dashboards.
By default, Query result caching is enabled. Turning off the query cache can help troubleshoot empty dashboards. You can re-enable it later for improved performance once the data is correctly displayed in the dashboards.

Troubleshooting steps

The most common reason for empty dashboards after installation is that none of the first downloaded Build Scan data have yet been compacted in MinIO for performant read operations in Grafana queries. The first time this compaction happens will correspond with when build data becomes visible in your Reporting Kit instance’s Grafana dashboards.
As a first step, validate that all Pods are up and running.
After deploying the Reporting Kit, it may take a short while until all Pods are running and ready.

Check the status of the Pods

Use the below kubectl command to check if all Pods are up and running and ready.

$ kubectl --namespace develocity-reporting-kit get pods
Output 
NAME                                 READY   STATUS    RESTARTS        AGE
minio-7b9d87c4c7-tsqss               1/1     Running   0               8m10s
grafana-5bd84f6bff-jhl8v             2/2     Running   0               8m10s
hive-metastore-7bfc5977b8-vwzkf      2/2     Running   0               8m10s
trino-worker-79f8ddfdd8-k6fc6        1/1     Running   0               8m10s
trino-coordinator-7d8794689-jrqn6    1/1     Running   0               8m10s
data-synchronizer-8489cd7749-gxv8h   1/1     Running   0               8m10s

If all Pods are running and ready, but your dashboards are empty, the data-synchronizer app may still be busy copying data to populate the first batch of Build Scan data, which will be compacted in MinIO for performant read operations. It can take several minutes for the data to appear in the dashboards.
By default Query result caching is enabled. Turning off the query cache will make it easier for you to troubleshoot empty dashboards. You can re-enable it afterward for improved performance once you’re satisfied that the data is showing up in the dashboards.

Check the logs for more information

If your dashboards are not displaying data after some time, check the logs of the main container of the data-synchronizer Pod for more information.
For example, if connectivity issues exist between the data-synchronizer app and the configured Develocity instance, that problem will appear in the logs of this container.
Use the below kubectl command to get the list of all running Pods of the Develocity Reporting Kit and look for the data-synchronizer Pod.

$ kubectl --namespace develocity-reporting-kit get pods
Output 
NAME                                 READY   STATUS    RESTARTS        AGE
minio-7b9d87c4c7-tsqss               1/1     Running   0               8m10s
grafana-5bd84f6bff-jhl8v             2/2     Running   0               8m10s
hive-metastore-7bfc5977b8-vwzkf      2/2     Running   0               8m10s
trino-worker-79f8ddfdd8-k6fc6        1/1     Running   0               8m10s
trino-coordinator-7d8794689-jrqn6    1/1     Running   0               8m10s
data-synchronizer-8489cd7749-gxv8h   1/1     Running   0               8m10s (1)
1 data-synchronizer-8489cd7749-gxv8h is the data-synchronizer Pod in this example.

In the next step use kubectl logs to gather more information about the Pod. This command will provide detailed information about the Pod, which will help troubleshoot.
Check the official kubectl logs documentation for more information about this command.

$ kubectl --namespace develocity-reporting-kit logs data-synchronizer-8489cd7749-gxv8h -c main
Output 
Defaulted container "main" out of: main, initializer (init), trino-schema-migrator (init)
2024-11-10 16:58:18,655 INFO c.g.d.r.d.DrkdsMain {} No app plugins loaded
2024-11-10 16:58:19,062 INFO r.s.RatpackServer {} Starting server...
2024-11-10 16:58:19,082 INFO r.s.RatpackServer {} Building registry...
2024-11-10 16:58:23,170 INFO r.s.RatpackServer {} Initializing 19 services...
2024-11-10 16:58:23,248 INFO c.g.d.q.Trino {eid=pwkw7olftx4d2} Validating Trino connection
2024-11-10 16:58:23,550 INFO c.g.d.q.Trino {eid=pwkw7olftx4d2} Connected to Trino version 450
2024-11-10 16:58:23,646 INFO c.g.d.r.Develocity {eid=6dlih6vbmbv66, peid=krc5dvy7poofy} Attempting to connect to Develocity https://develocity.example.com with key starting with rw7…
2024-11-10 16:58:23,745 INFO r.s.RatpackServer {} Ratpack started for http://localhost:8080
If you see stack traces in the logs and worry that something might be wrong, contact the Develocity support team by creating a support ticket.

  • If you encounter any errors about authentication and permissions, ensure that you followed the Develocity configuration section and configured a Develocity access key and API permissions.

  • If you see any errors related to TLS/SSL, check the documentation about Trusted TLS certificates and TLS.

If you have any questions or need any assistance please contact the Develocity support team or your customer success representative.

Appendix

Appendix A: Release history

1.2

10th December 2024

  • [NEW] The following new dashboards have been added: Dependencies, Realized Configuration Cache Savings, Realized Test Acceleration Savings, Predictive Test Selection Savings Potential. They require build models which are present from Develocity version 2024.3 onwards.

  • [NEW] The Plugins Overview dashboard has been renamed to Plugins, and contains improved filtering, performance, and more data visualizations.

  • [NEW] Custom trusted CA certificates can be configured so that builds can be pulled from a Develocity instance using a TLS certificate signed by an internal CA.

  • [FIX] Improved security configuration for Trino.

  • [FIX] Deterministic Helm template output can be configured without using any inline secret values.

Appendix B: Develocity compatibility

The below lists the minimum versions of Develocity required to populate the dashboards in the Reporting Kit. If a dashboard or panel is not explicitly mentioned, it is supported from the baseline Develocity version of 2023.4 onwards.

Develocity version Compatibility

2024.3

support for all previous dashboards and panels, and

  1. Dependencies dashboard

  2. Realized Configuration Cache Savings dashboard

  3. Realized Test Acceleration Savings dashboard

  4. Predictive Test Selection Savings Potential dashboard

2024.2

support for all previous dashboards and panels, and

  1. Plugins dashboard

  2. Plugins panel in the Project Volume dashboard

  3. Gradle CPU Usage dashboard

  4. Maven CPU Usage dashboard

2024.1

support for all previous dashboards and panels, and

  1. Gradle Build Deprecations dashboard

  2. Gradle Build Deprecations panel in the Project Volume dashboard

2023.4

minimum required version for use with the Develocity Reporting Kit

Appendix C: Deterministic Helm output

By default, the Helm chart generates several random secrets. Some Helm chart deployment tools, such as ArgoCD, will re-run Helm to compare the rendered Kubernetes manifests with the resources that are installed in the cluster, and reinstall the Helm chart if they are different. For this to work correctly, the output of helm template must be deterministic. It is possible to get deterministic output from the Develocity Reporting Kit Helm chart by fixing randomly generated values so that they are not regenerated during template rendering.

Using inline configuration

One way to do this is by setting all randomly generated values inline in your Helm values.

Here is an example Helm config showing the values you need to set:

values.yaml 
global:
  license:
    file: "..."

develocity:
  address: "..."
  accessKey: "..."

ingress:
  hostname: "..."
  ssl:
    enabled: true
    cert: "..."
    key: "..."

grafana:
  securityKey:
    value: "..."
  adminAccount:
    password: grafana-admin-password

minio:
  rootAccount:
    password: minio-root-password
  dataSynchronizerAccount:
    password: minio-syncApp-password
  trinoAccount:
    password: minio-trino-password
  trinoCacheAccount:
    password: minio-trinoCache-password

trino:
  internalCommunicationSecret:
    value: "..."
  systemAccount:
    credentials:
      basic:
        user: trino-system
        password: trino-system-password
  userAccount:
    credentials:
      basic:
        user: trino-user
        password: trino-user-password
  cache:
    ssl:
      cert: "..."
      key: "..."
  coordinator:
    ssl:
      cert: "..."
      key: "..."

Using user-managed secrets

Another way to do this is by creating the following user-managed secrets, and then configuring the Helm chart with the secret names:

  • develocity.accessKey.secretName, secret must have a single accessKey property.

  • ingress.ssl.secretName (or set both ingress.ssl.cert and ingress.ssl.key directly in the chart), only necessary if ingress SSL is enabled.

  • grafana.securityKey.secretName, secret must have a single key property.

  • grafana.adminAccount.secretName, secret must have a single password property.

  • minio.rootAccount.secretName, secret must have a single password property.

  • minio.dataSynchronizerAccount.secretName, secret must have a single password property.

  • minio.trinoAccount.secretName, secret must have a single password property.

  • minio.trinoCacheAccount.secretName, secret must have a single password property.

  • trino.internalCommunicationSecret.secretName, secret must have a single password property.

  • trino.systemAccount.credentials.basic.secretName, secret must have user and password properties.

  • trino.userAccount.credentials.basic.secretName, secret must have user and password properties.

The following SSL certificates can’t currently be set with a user-managed secret and need to be specified inline: - trino.cache.ssl.cert and trino.cache.ssl.key - trino.coordinator.ssl.cert and trino.coordinator.ssl.key

Here is an example Helm config showing the values you need to set:

values.yaml 
global:
  license:
    file: "..."

develocity:
  address: "..."
  accessKey:
    secretName: example-develocity-access-key-secret

ingress:
  hostname: "..."
  ssl:
    enabled: true
    secretName: ingress-ssl-secret

grafana:
  securityKey:
    secretName: grafana-security-key-secret
  adminAccount:
    secretName: grafana-admin-account-secret

minio:
  rootAccount:
    secretName: minio-root-account-secret
  dataSynchronizerAccount:
    secretName: minio-syncApp-account-secret
  trinoAccount:
    secretName: minio-trino-account-secret
  trinoCacheAccount:
    secretName: minio-trinoCache-account-secret

trino:
  internalCommunicationSecret:
    secretName: trino-internal-secret
  systemAccount:
    credentials:
      basic:
        secretName: trino-system-credentials-secret
  userAccount:
    credentials:
      basic:
        secretName: trino-user-credentials-secret
  cache:
    ssl:
      secretName: trino-cache-ssl-secret
  coordinator:
    ssl:
      secretName: trino-coordinator-ssl-secret

Appendix E: Installing into the same Kubernetes cluster as Develocity

It is possible to install the Reporting Kit into the same Kubernetes cluster as Develocity.

If Develocity is installed using the standalone Helm chart into a K3s cluster on a single host, please see below for resource considerations.

Appendix D: Installing into the same Kubernetes namespace as Develocity

When configuring the Develocity Reporting Kit to pull data from a Develocity instance that runs in the same namespace as the Develocity Reporting Kit, set the develocity.address Helm value to the Develocity installation’s gradle-proxy Kubernetes service address. The URL should be http://gradle-proxy:80.

values.yaml 
develocity:
  address: "http://gradle-proxy:80"
  accessKey: "..."

Installing into a different Kubernetes namespace as Develocity

When configuring the Develocity Reporting Kit to pull data from a Develocity instance that runs in a different namespace of the same cluster as the Develocity Reporting Kit, set the develocity.address Helm value to a cluster-local address based on the Develocity namespace. The URL should be http://gradle-proxy.«develocity-namespace».svc.cluster.local.

For a Develocity instance installed in the develocity namespace, this would look like:

values.yaml 
develocity:
  address: "http://gradle-proxy.develocity.svc.cluster.local"
  accessKey: "..."

Standalone Develocity resources

We do not recommend installing the Reporting Kit into the same standalone instance as Develocity. If there are no other options though, it can be done with some additional resource limits put in place for the Reporting Kit.

Please consider the Reporting Kit resource requirements and Develocity’s standalone resource requirements. At time of writing the most significant were 64GB of RAM for the Reporting Kit, and 16 GB RAM for Develocity. If your Develocity instance has been tuned to use more memory, please use that in subsequent calculations.

If your instance has enough memory for both applications, proceed without further configuration. It is possible to install both Develocity and the Reporting Kit into a single host with for example, only 64GB of memory by tuning down the Reporting Kit’s memory consumption. To do so, make the following adjustment:

values.yaml 
trino:
  worker:
    resources:
      requests:
        memory: 24Gi
      limits:
        memory: 32Gi

If your host has less memory, you will need to adjust these values lower.

Note that when running the Reporting Kit with constrained memory, it is possible that some data sets will not be able to populate the dashboards. If you see errors in the dashboards relating to memory, try requesting a shorter window for example, just 2 days instead of the default or 7 days. This will require less memory to process.

Appendix F: Storing data in a specified directory for a standalone installation using K3s

For users intending to install the Reporting Kit onto a single node using K3s, you may want to specify a particular directory on the installation machine in which the application should store its data.

To do this requires taking the below steps:

If you already have data stored somewhere that isn’t your mounted data directory, these steps will not move the data into the right place. To get help with that problem, contact Gradle support.

1. Patch the K3s local-path-provisioner configuration

This instructs the local-path-provisioner to store Kubernetes application data within the directory of your choosing.

$ cat > local-path-config-patch.yaml << EOF
data:
  config.json: |-
    {
      "nodePathMap":[
      {
        "node":"DEFAULT_PATH_FOR_NON_LISTED_NODES",
        "paths":["/your/storage/directory"](1)
      }
      ]
    }
EOF
1 The directory in which you want the application to store data. 
kubectl -n kube-system patch configmap/local-path-config --patch-file local-path-config-patch.yaml (1)
1 This applies the config patch.

2. Recreate the K3s local-path-provisioner Pod

This is done by deleting the Pod, which will cause it to be immediately recreated and pick up the configuration change.

kubectl -n kube-system delete "$(kubectl -n kube-system get pods --selector "app=local-path-provisioner" --output "name")"

The Pod should come back up within a few seconds, and now all new provisioned storage in the K3s cluster using the local-path storage class (which is the default) will be stored in the directory you configured in the first step.

Appendix G: Installing the Develocity Reporting Kit on OpenShift

If you are planning to install the Reporting Kit in an OpenShift cluster, you should configure your installation to disable Pod security contexts.

Appendix H: Query result caching

The Reporting Kit includes a persistent query result cache for the Trino query engine. This cache is enabled by default and is used to store the results of all queries that are executed from within Grafana. Once the results of a query have been cached, subsequent identical queries will return the cached results instead of executing the query again. Cache entries expire by default after 1 day, they are not invalidated when new data is ingested by the Reporting Kit.

The cache uses the query string as-is as the cache key, so any differences in the query string will result in a cache miss.

Disabling the query result cache

In some cases, such as when building alerting rules that depend on real-time data, you may want to use a lower cache retention or even completely disable the cache for a specific query. You can configure the cache retention at the query level by prefixing the query string with a special SQL comment:

-- trino.cache.retention=5m
SELECT count(id) AS "Build count" FROM build

Or, to entirely disable the cache for a specific query:

-- trino.cache.retention=0
SELECT count(id) AS "Build count" FROM build

You can adjust the default cache entry retention period or disable query caching entirely by configuring your Helm values.

Issues with editing queries in Grafana

The cache sometimes interferes with the query editing experience in Grafana, resulting in infinite processing when submitting a query. To circumvent this issue, it’s advisable to disable the cache as explained above during the time you are editing the query.

Appendix I: Disabling HTTPS communication between Reporting Kit components

Starting with version 1.2, the Develocity Reporting Kit uses HTTPS for internal communication by default. All queries reaching Trino must be issued from authenticated sources with valid credentials, such as those preconfigured for the Grafana instance.

The use of HTTPS to communicate between components may be incompatible with some environments, particularly those using a service mesh, such as Istio. In such cases, you can disable HTTPS by setting the Helm value trino.internal.https.enabled to false.

An example of how to do this is shown below:

values.yaml 
trino:
  internal:
    https:
      enabled: false
We don’t recommend disabling HTTPS unless you have to, because when HTTPS is disabled, Trino will not attempt to authenticate query requests, which is insecure.