Standalone Helm Chart Configuration Guide

Develocity is a Kubernetes-based application, distributed as a Helm chart. Helm is a package manager for Kubernetes applications.

Helm manages all Develocity components.

Helm Overview

To use Helm, users must first import a Helm chart. 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 sample values.yaml file:

values.yaml

global:
  hostname: develocity.example.com
database:
  type: embedded
ingress:
  enabled: true

Helm configuration can be provided in several ways:

Passing values directly to the helm command using --set or --set-file.
Creating a Helm values file and passing it to helm using --values.
Editing the default Helm values file in the chart prior to running helm.

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

helm install --values ./values.yaml

Unless otherwise indicated, most values are optional and have usable defaults.

Example Helm Values File

A complete example of the values file can be found here.

Considerations

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

Global Options (Hostname, License)
Database Type (Embedded or External)
Storage Settings
Networking Options (Ports, Proxies, SSL)
Object Storage
Unattended Configuration
Using an external Bazel cache

For installations on hosts with limited to no network connectivity, see the additional section:

Airgap Installation

By the end of this guide, you will have a complete values.yaml file, ready for your Develocity installation with storage, networking, database settings, and more.

Helm Options

1. Global Options

Hostname

When installing Develocity, a hostname such as develocity.example.com is required.

This should be the hostname that users of the installation use to access it and therefore should resolve within your network. It is usually the name of the Develocity host or the hostname of a reverse proxy if one is being used.

Develocity will only accept requests with this hostname in their Host header.

A hostname for the application is supplied in the Helm values file as follows:

values.yaml

global:
  hostname: develocity.example.com

License

You have been provided with a Develocity license file called develocity.license.

This file can be used in any testing, staging or production deployments of Develocity.

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

The license file can also be supplied as a helm argument using --set-file.

2. Database Options

Develocity can store data in either:

An embedded database that uses a local directory or volume to store its data.
A user-managed database that is completely separate from Develocity.

There are tradeoffs to consider for each option:

Embedded database tradeoffs

When using the embedded database, Develocity will run a PostgreSQL database in a container and store data in a local directory. In this mode Develocity can run backups on a regular or cron-like schedule.

The embedded database has several advantages:

Simple setup with no additional configuration needed.
Automatic updates to the latest PostgreSQL version supported.
Features that require disk space information are supported.
Typically more affordable for smaller installations.

However, there are downsides to the embedded database, in particular for larger installations:

Disk I/O throughput can be a bottleneck on a busy system and is difficult to address.
Backup management is slow for larger databases, creates a load on the server, and consumes a lot of memory.
It is not possible to keep a standby database.
The database is a single point of failure.

User-managed database tradeoffs

A user-managed database can be any PostgreSQL 12, 13, or 14 compatible database. Popular options also include cloud-based database providers such as Amazon RDS or Aurora. There are a number of advantages, particularly in large installations:

Database customizations and optimizations are possible (memory, CPU, I/O throughput, etc…).
Resources can be allocated for cost-effectiveness.
Third party tools to snapshot the database can be used.
Many cloud databases allow for easy scaling of resources post installation.
A standby database for fail-over protection can be used.

There are some downsides to using a user-managed database:

Extra system(s) are needed for provisioning and configuration.
Database connectivity and network latency is a factor.
Backups must be managed by an administrator or a tool.
Disk space management and alerting are required.
Develocity features related to disk space are not available.
Security considerations such as credential cycling must be considered.
Customer support may be limited for disaster recovery or backup restores.

By default, Develocity will use an embedded database. For this configuration, no additional values are needed in the Helm values file.

User-managed database configuration

When Develocity is configured to store data in a user-managed database, it must be provided with connection settings and credentials for the database.

Connection settings

Standard connection settings like host, port, and database name must be provided in the values file. JDBC parameters can be optionally specified as well:

values.yaml

database:
  location: user-managed
  connection:
    host: database.example.com (1)
    port: 5432 (2)
    databaseName: gradle_enterprise (3)
    params: "?connectTimeout=60" (4)

1	The database URL.
2	The `port` property is optional.
3	The database must have already been created using `CREATE DATABASE`, the `createdb` command or an equivalent mechanism in a cloud database interface prior to configuring Develocity with connection details.
4	The `params` property is optional.

Credentials

There are three options for credentials:

Option 1 - superuser

If provided with credentials for a database superuser (such as the postgres user that is common on PostgreSQL database instances), Develocity can perform the database setup.

A superuser can be added to the values file in the database section:

values.yaml

database:
  location: user-managed
  connection: ...
  credentials:
    superuser:
      username: postgres
      password: the_password

In some installations, often cloud-based, the default credentials provided are not a superuser. For example, the supplied postgres account in Amazon RDS Postgres databases is not a superuser, but has the rds_superuser role. Such accounts are typically acceptable to use with Develocity.

Option 2 - no superuser

To set up your database without database superuser credentials, run the setup.sh script from the database setup scripts for your Develocity version against it. The script will set up less privileged accounts for the application to use, and some privileged functions needed for the application to run.

The installation will fail if you do not run the database setup scripts.

The credentials for the accounts must be set by you and provided to Develocity via Helm configuration.

To set up your database without database superuser credentials, the values file must be updated as follows:

values.yaml

database:
  location: user-managed
  connection: ...
  credentials:
    app:
      password: app_password
    migrator:
      password: migrator_password

Option 3 - AWS IAM database authentication (with or without superuser)

Develocity can be configured to acquire short-lived passwords dynamically using IAM database authentication, rather than using any stored password credentials. This makes it possible to for you to manage access to the Develocity database without managing passwords directly. Using IAM database authentication requires that your database is an instance of either Amazon RDS or Amazon Aurora, and that your Develocity instance is running on an Amazon EC2 instance.

To configure Develocity to use IAM database authentication, your database credentials Helm config needs to include information about your database provider and how Develocity should acquire short-lived passwords. If you want Develocity to perform database setup automatically when starting, you also need to configure superuser access.

The Helm value database.provider must be set to aws-rds, and the Helm value database.credentials.type must be set to instanceProfile, which refers to the use of EC2 instance profiles.

Instance profile credentials can only be used if your Develocity installation is running on an Amazon EC2 instance.

You must set up the appropriate permissions in AWS beforehand in order for Develocity to be able to acquire short-lived passwords using an EC2 instance profile. The steps to do this are described in the IAM database authentication for RDS section of our Amazon EC2 Standalone Installation Guide.

To configure Develocity to acquire short-lived database passwords using instance profile credentials, update your Helm values file as follows:

values.yaml

database:
  location: user-managed
  connection: ...
  provider: aws-rds
  credentials:
    type: instanceProfile

Database setup with IAM database authentication

Database setup must either be performed automatically by Develocity on startup by connecting to the database as a superuser, or it must be performed manually by you prior to installation by running the setup.sh script from the database setup scripts for your Develocity version against the database.

If you want Develocity to be able to connect to the database as a superuser for automatic database setup, you need to provide either the username of a superuser (in which case Develocity will try to connect as the superuser using IAM authentication), or both the username and password of a superuser (in which case Develocity will try to connect as the superuser using the configured password). These can be provided directly using the Helm values database.credentials.superuser.username and database.credentials.superuser.password, or in a Kubernetes Secret, whose name must be provided in the Helm value database.credentials.superuser.secretName and which contains just either a username, or both a username and a password.

If you want to specify superuser credentials using a Kubernetes Secret, it should have the typical username and password keys, encoded using Base64:

---
apiVersion: v1
kind: Secret
metadata:
  name: my-example-db-superuser-credentials
data:
  username: "cG9zdGdyZXM="
  password: "ZXhhbXBsZS1wYXNzd29yZA=="

3. Storage Settings

By default, the Develocity standalone distribution stores its data at /opt/gradle, and logs and backups are stored in subdirectories of that directory. To simplify managing disk space, however, Gradle recommends mounting a different persistent storage volume for Develocity data, logs, and backups.

To alter the location of backups, update the values.yaml file as follows:

values.yaml

global:
  storage:
    directory: /mnt/high-performant-volume/develocity-data           # Default /opt/gradle
    logs:
      directory: /mnt/standard-volume/develocity-logs       # Default (global.storage.directory)/logs
    backup:
      directory: /mnt/big-volume/develocity-backups       # Default (global.storage.directory)/backups

Develocity standalone installations do not permit configuring different storage volumes for the Build Cache and the database.

4. Networking Options

There are a number of considerations for Develocity related to connectivity:

HTTP or HTTPS (with SSL certificates)
Application Ports
Proxies

HTTP or HTTPs

Develocity can be configured to securely serve traffic over HTTPS based on user-provided certificates.

If certificates are not supplied, self-signed certificates will be generated and used, though this is not recommended for production operation.

HTTPS Terminated at Ingress

When using the Develocity supplied Ingress, HTTPS is enabled by default.

It can be disabled to serve traffic over HTTP only:

values.yaml

ingress:
  enabled: true
  ssl:
    enabled: false

SSL certificates (trusted or untrusted) can be provided inline in the values file:

values.yaml

ingress:
  enabled: true
  ssl:
    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-----

This file can also be passed using the --set-file flag with your helm command.

HTTPS SSL Certificate

It is strongly recommended that production installations of Develocity are configured to use HTTPS with a trusted certificate.

Develocity natively supports serving traffic over HTTPS when configured with a certificate and key. If you intend to use an ingress controller for directing external traffic to Develocity, you may opt to terminate HTTPS there. It is also possible to terminate HTTPS connections in an external reverse proxy.

Untrusted SSL Certificates

By default, Develocity uses the default trust settings of the Java runtime that it ships with when connecting to other systems using SSL.

If your organization uses certificates that are not signed by a trusted certificate authority, you must perform additional configuration for this to work. This may be the case if you use self-signed certificates or an internal certificate authority.

Trusted and Additional SSL Certificates

Additional trusted certificates can be specified at installation time via the unattended configuration mechanism, using the additionalTrust field in the unattended configuration file. The value of this field should be the X509 certificates to trust in PEM format, newline-separated if there are more than one.

For example, using the inline Helm values support to include the unattended config in a values file:

values.yaml

global:
    unattended:
      configuration:
        version: 11
        systemPassword: ...
        network:
         additionalTrust: |
             -----BEGIN CERTIFICATE-----
             MIIDfzCCAmegAwIBAgIURqPslYGu7cHXs22q3RK6e5L87PwwDQYJKoZIhvcNAQEL
             ...
             s10yB5VjVBES6A22rYwYb8mImpQiVP/mr4ao5U5m+h50l3E=
             -----END CERTIFICATE-----
             -----BEGIN CERTIFICATE-----
             DSE3a3CCAmegAwIBAgIURqPslYGu7cHXs22q3RK6e5L87PwwDQYJKoZIhvcNAQEL
             ...
             s10yB5VjVBES6A22rYwYb8mImpQiVP/mr4ao5U5m+h50l3E=
             -----END CERTIFICATE-----

HTTPS Terminated Externally

In many setups, a reverse proxy or load balancer will perform SSL termination. In this case, SSL certificates must be configured accordingly.

Develocity needs to know that the application will be accessed over externally terminated HTTPS. This is done with the following configuration:

values.yaml

global:
  hostname: develocity.example.com
  externalSSLTermination: true

If you’re using the provided Ingress, you may wish to communicate between the load balancer and the application using HTTP by disabling SSL at the Ingress:

values.yaml

ingress:
  enabled: true
  ssl:
    enabled: false

Application Ports

The ports that the application accepts traffic on can be altered from the default of 443 (or 80 if accepting plain HTTP) as follows:

values.yaml

ingress:
  enabled: true
  port:
    http: 8080
    https: 8443

Proxy Configuration

By default, Develocity requires an internet connection to make several outbound HTTP requests (such as license validation).

In case your organization requires all outbound HTTP traffic to go through an HTTP proxy, you must perform additional configuration for this to work as part of the unattended configuration.

5. Object Storage Configuration

The 2024.3 release significantly changes the Object Storage configuration by removing deprecated configurations. Please review the changes in the Develocity Upgrade Guide before upgrading.

Develocity can store two kinds of data in a user-managed object storage service, such as Amazon S3:

Build Scan data is stored in the database by default, but Develocity can be configured to store Build Scans in an object store instead.
Build Cache data is stored in embedded object storage - a persistent volume backed server installed with Develocity - by default, but can be configured to store Build Cache data in a user-managed object store instead.

The Build Scan object storage section of the Administration Manual discusses the tradeoffs of using object storage rather than a database for Build Scan data. We recommend that your object storage is hosted close to your Develocity installation to minimise latency and network usage costs. For example, if using S3 as an object storage service, verify that your S3 bucket and Develocity installation reside in the same AWS region.

Most popular object storage services are supported. Alternatively, Develocity ships with the ability to run an embedded object store as one of its components. The rest of this section describes how to configure Develocity to use AWS S3, an S3-compatible object storage service, Google Cloud Storage, Microsoft Azure Blob Storage, or the embedded object storage.

To finish configuring Develocity to store Build Scans in the configured object storage, you must also configure Develocity with an unattended configuration stanza in your Helm values.yaml file. See Object Storage for Build Scans for details.

If Develocity is connected to a user-managed object storage service, then Develocity will switch to storing Build Cache data there, instead of embedded object storage.

Amazon S3

The S3 object storage section of the Amazon EC2 Installation Guide describes steps for setting up a bucket in S3 with an appropriate access policy.

To use Amazon S3 as the object store for Develocity, you need to set the type of the object storage as s3 and configure the bucket name and region.

values.yaml

objectStorage:
  type: s3
  s3:
    bucket: example-bucket (1)
    region: example-aws-region-1 (2)
    credentials:
      #...

1	Your S3 bucket name.
2	The cloud provider region where your object storage resides.

It is necessary to provide credentials to access the bucket. There are several options to do this as documented below.

If Develocity is hosted on AWS, it is strongly recommended to setup and configure access to the S3 bucket via a VPC endpoint to reduce access cost and latencies. Refer to the official AWS VPC endpoint documentation to learn more.

Instance Profile credentials configuration

You can provision credentials to Develocity dynamically using EC2 instance profiles.

values.yaml

objectStorage:
  type: s3
  s3:
    bucket: example-bucket
    region: example-aws-region-1
    credentials:
      type: instanceProfile

Keys credentials configuration

To provide an access key and secret key as credentials in the Helm chart, set type to keys and provide the accessKey and secretKey.

values.yaml

objectStorage:
  type: s3
  s3:
    bucket: example-bucket
    region: example-aws-region-1
    credentials:
      type: keys
      keys:
        accessKey: "AKIA1234ABCD7890"
        secretKey: "dfml3s9rfdlsok390wledck30rkdfs"

Custom endpoint

There are circumstances in which it is necessary to specify the endpoint URL of the service:

If you need to connect to S3 directly from a VPC using a gateway VPC endpoint.
If your object storage service is not S3 but provides an S3-compatible interface.

To do this, set the endpoint property to point to the service endpoint:

values.yaml

objectStorage:
  type: s3
  s3:
    bucket: example-bucket
    endpoint: https://object-store.example.com
    credentials:
      #...

Google Cloud Storage

To use Google Cloud Storage as the object storage, set the type of object storage as googleCloudStorage and configure the bucket.

values.yaml

objectStorage:
  type: googleCloudStorage
  googleCloudStorage:
    bucket: example-bucket
    credentials:
      #...

It is necessary to provide credentials to access the bucket.

Service Account Key credentials configuration

To provide the service account key as credentials in the Helm chart, set type to serviceAccount and provide the key.

values.yaml

objectStorage:
  type: googleCloudStorage
  googleCloudStorage:
    bucket: example-bucket
    credentials:
      type: serviceAccount
      serviceAccount:
        key: |
          {
            "type": "service_account",
            "project_id": "PROJECT_ID",
            "private_key_id": "KEY_ID",
            "private_key": "-----BEGIN PRIVATE KEY-----\nPRIVATE_KEY\n-----END PRIVATE KEY-----\n",
            "client_email": "SERVICE_ACCOUNT_EMAIL",
            "client_id": "CLIENT_ID",
            "auth_uri": "https://accounts.google.com/o/oauth2/auth",
            "token_uri": "https://accounts.google.com/o/oauth2/token",
            "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
            "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL"
          }

Azure Blob Storage

To use Azure Blob Storage as the object storage, set the type of the object storage as azureBlobStorage and configure the container name.

values.yaml

objectStorage:
  type: azureBlobStorage
  azureBlobStorage:
    container: example-container
    credentials:
      #...

It is necessary to provide credentials to access the bucket.

Account Key credentials configuration

To provide an account name and key in the Helm chart, set type to accountInformation and provide the accountName and accountKey properties.

values.yaml

objectStorage:
  type: azureBlobStorage
  azureBlobStorage:
    container: example-container
    credentials:
      type: accountInformation
      accountInformation:
        accountName: "example-account"
        accountKey: "dfml3s9rfdlsok390wledck30rkdfs"

Embedded object storage

Embedded object storage is a component that is deployed as part of the Develocity installation if no other object storage is configured. Data will be stored on the local disk under the configured storage directory.

The default embedded object storage size limit is 10 GiB. The limit can be increased by setting a custom value for objectStorage.embedded.storage.buildCache.capacity.

values.yaml

objectStorage:
  type: embedded
  embedded:
    storage:
      buildCache:
        capacity: 20Gi  # Default 10Gi

Data in the embedded object store is not part of a Develocity database backup.

Configuring advanced parameters

Each object storage provider can be further configured using advancedParams. You should only configure advanced parameters if you have been directed to do so by Develocity support.

values.yaml

objectStorage:
  type: s3
  s3:
    bucket: example-bucket
    region: example-aws-region-1
    credentials:
      type: irsa
    advancedParams:
      client.maxConcurrency: 12

6. Unattended Configuration

Many aspects of Develocity’s behaviour can be configured via the Admin user interface or by providing an unattended configuration file. These settings are described in the unattended configuration section of the Develocity Administration Manual.

Unattended configuration settings can also be in their own yaml file and given to the helm command as follows: --set-file global.unattended.configuration=./unattended-config.yaml

While most of Develocity can be configured post-installation, there are two items that can and should be configured at installation time:

Proxy settings
Object Storage for Build Scans

In order to use the unattended configuration in your Helm values file, you will need the hashed system user password and a configuration version. The Develocity Admin CLI must also be installed. Full instructions are available in the Administration Manual.

Proxy Settings

HTTP proxy configuration can be specified under the network section in the unattended configuration section:

values.yaml

global:
    unattended:
      configuration:
        version: 11 (1)
        systemPassword: "«hashed-system-password»" (2)
        network:
         proxy:
           protocol: http (3)
           host: proxy.gradle.com (4)
           port: 8080 (5)
           excludedHosts: (6)
             - some.external
             - '*.internal'
           auth: (7)
             username: proxy_user
             password: "aes256:B0uVHRDhng+PraUI:2bOz71vKTexz0QH5:z7lO+1wOC/tA3izLAwV0BXMugg=="

1	The version of the unattended configuration. See the Administration Manual.
2	Your hashed system password. See the Administration Manual.
3	The protocol used to connect to the proxy. Note that this is not the protocol used to connect to the destination/target addresses. Supported values are `http` and `https`, if no value is provided `http` will be used as the default protocol.
4	HTTP proxy host name.
5	HTTP proxy port, if no value is provided `80` will be used ad the default port.
6	A comma-delimited list that controls what hosts should not be proxied. The list can contain individual host names as well as domain patterns (e.g. '*.internal') which match all hosts for a particular domain. Any requests sent to these hosts will be sent directly rather than being sent through the HTTP proxy.
7	A username and password used to authenticate with the HTTP Proxy.

Object Storage for Build Scans

To configure Develocity to store incoming Build Scan data using your object storage service bucket or container, add the following to your Helm values file:

values.yaml

global:
  unattended:
    configuration:
      version: 11 (1)
      systemPassword: "«hashed-system-password»" (2)
      buildScans:
        incomingStorageType: objectStorage
      advanced:
        app:
          heapMemory: 5632 (3)

objectStorage: (4)
  type: s3
  s3:
    bucket: example-bucket
    region: example-aws-region-1
    credentials:
      type: irsa

1	The version of the unattended configuration. See the Administration Manual.
2	Your hashed system password. See the Administration Manual.
3	If you have already set a custom value here for heap memory, increase it by `2048`.
4	The object storage stanza you created in 5. Object Storage Configuration. If you set `incomingStoragetype` to `objectStorage`, then you must configure an object storage service with this stanza in `values.yaml` for your Develocity instance.

7. Using an external Bazel cache

If you wish to use Build Scans for your Bazel builds while using a remote cache other than the one built into Develocity, you will need to configure the necessary details. Please note that your remote cache must expose a GRPC endpoint for Develocity to be able to speak to it.

The only mandatory value is the host and port of your external cache:

values.yaml

enterprise:
    bazel:
        remoteCacheConnection:
            url: grpc{s}://<hostname>:<port>

If your external cache allows anonymous reads, this is the only value you need. Otherwise, see the section on authentication.

Trusting a server certificate

See the section on Untrusted SSL certificates.

Authenticating to an external Bazel cache

All configuration of authentication to a Bazel cache will take the following form:

values.yaml

enterprise:
    bazel:
        remoteCacheConnection:
            url: grpc{s}://<hostname>:<port>
            authType: <AUTH_TYPE>
            auth:
                <AUTH_TYPE>:
                    ...

Please note that any credentials you provide must allow a user to read from the cache.

The following authentication methods are currently supported:

Bearer token authentication

In this authentication method, an external token will be passed to the server in the Authorization header prefixed by "Bearer" - Bearer <token>. The configuration for this scenario should look like this:

values.yaml

enterprise:
    bazel:
        remoteCacheConnection:
            url: grpc{s}://<hostname>:<port>
            authType: bearerToken
            auth:
                bearerToken:
                    token: <TOKEN>

TLS client authentication

In this authentication method, a client certificate + key will be used to authenticate to the cache. Please note that the certificate and key must be separate values and in PEM format. You can provide these values directly, in which case the configuration looks like this:

values.yaml

enterprise:
    bazel:
        remoteCacheConnection:
            url: grpc{s}://<hostname>:<port>
            authType: tls
            auth:
                tls:
                    cert: |-
                        <PEM_FORMATTED_CERT>
                    key: |-
                        <PEM_FORMATTED_KEY>

8. Airgap Installations

Develocity can be run on hosts without internet connectivity, referred to as an airgap installation.

Airgap Configuration

In an airgap installation, Helm is configured so that no attempt is made to pull images from the outside world with the values below:

values.yaml

global:
  image:
    imagePullPolicy: Never

Your values.yaml file is complete. You can return to the installation manual.

Changing Configuration Values

To change configuration values without changing the version of Develocity, you need to specify the current installed Develocity version.

It’s important to specify the Develocity 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 deployed Develocity version, run:

$ helm history --namespace develocity ge --max 1

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

$ helm upgrade \
    --namespace develocity \
    ge gradle/{chartName} \
    --version «deployed-version» \(1)
    --reuse-values \
    «new values options»

1	`«deployed-version»` is the deployed version of Develocity.

Or for a Helm-managed airgap installation:

$ helm upgrade \
    --namespace develocity \
    ge {chartName}-«deployed-version».tgz \(1)
    --version «deployed-version» \
    --reuse-values \
    «new values options»

1	`«deployed-version»` is the deployed version of Develocity.

The above examples reuse previous values by default. Any specified values will override the existing values.
If you want to specify all values explicitly (ignoring any previously set values), run with --reset-values instead of --reuse-values.

Watch Out

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.

If you have any questions or need any assistance don’t hesitate to get in touch with the Develocity support team or your customer success representative.

Appendix A: Example Helm Values File

You can download and verify the example Helm values file with the following commands:

$ curl -L -o example.values.yaml https://docs.gradle.com/enterprise/helm-standalone-installation/values-2024.3/gradle-enterprise-standalone-values-2024.3.yaml

$ curl -L -o example.values.yaml.sha256 https://docs.gradle.com/enterprise/helm-standalone-installation/values-2024.3/gradle-enterprise-standalone-values-2024.3.yaml.sha256

$ echo "$(cat example.values.yaml.sha256)  example.values.yaml" | sha256sum -c

A direct download is available below.

gradle-enterprise-standalone-values-2024.3.yaml Download (SHA-256 checksum, PGP signature, PGP signature SHA-256 checksum)