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

Helm manages all Gradle Enterprise 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 Gradle Enterprise installation with information such as networking, database, or hostname settings.

Here is a sample values.yaml file:

values.yaml 
global:
  hostname: ge.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 Gradle Enterprise 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 Gradle Enterprise installation options and their corresponding values.yaml variables:

  1. Global Options (Hostname, License)

  2. Horizontal Scaling Options

  3. Database Type (Embedded or External)

  4. Storage Settings

  5. Routing Options (Ingress, NodePort, LoadBalancer, OpenShift)

  6. Networking Options (Ports, Proxies, SSL)

  7. Unattended Configuration

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

  1. Airgap Installation

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

Helm Options

1. Global Options

Hostname

When installing Gradle Enterprise, you will need to provide a hostname such as ge.example.com.

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 Gradle Enterprise host or the hostname of a reverse proxy if one is being used.

Gradle Enterprise 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: ge.example.com

License

You have been provided with a Gradle Enterprise license file called gradle-enterprise.license.

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

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.

It is also possible to specify the license file as a Kubernetes secret. This can then be managed manually, or by tooling such as Sealed Secrets or AWS Secrets Manager.

To manually create a secret with the Gradle Enterprise license:

$ kubectl create secret generic my-example-license-secret --from-file=license=path/to/gradle-enterprise.license

Then configure Helm with the name of the secret:

values.yaml 
global:
  license:
    secretName: my-example-license-secret

When specifying the license as a secret, an image pull secret must also be specified.

If performing an airgap installation, an image pull secret must be supplied anyway if the internal registry requires authentication.

If performing an online installation, the license file also needs to be created as an image pull secret:

$ kubectl create secret docker-registry my-example-license-image-pull-secret \
    --docker-username=ignored \
    "--docker-password=$(cat ./enterprise/internal-installs/gradle-enterprise.license)" \
    --docker-server=registry.gradle.com
values.yaml 
global:
  image:
    imagePullSecret: my-example-license-image-pull-secret

2. Horizontal Scaling Options

A number of Gradle Enterprise components can be scaled horizontally to provide greater performance and higher availability.

values.yaml 
global:
  scaling:
    replicas: 2

Gradle Enterprise’s scalable components are implemented as Kubernetes StatefulSet resources. It is also possible to alter their replica count directly using kubectl scale, allowing integration with other Kubernetes tooling.

It is only recommended to alter the replica count directly when connecting to a user-managed database, as available embedded database connections are configured based on the replica count. The user-managed database should have (160 ✖️ replica count) connections available.

3. Database Options

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

There are tradeoffs to consider for each option:

Embedded database tradeoffs

When using the embedded database, Gradle Enterprise will run a PostgreSQL database in a container and store data in a persistent volume. In this mode Gradle Enterprise 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.

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.

  • Gradle Enterprise 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, Gradle Enterprise will use an embedded database that stores its data in a persistent volume provided by the cluster. For this configuration, no additional values are needed in the Helm values file.

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

These can be provided either to Helm as configuration or as Kubernetes ConfigMap and Secret resources. Configuring these in Helm is the simplest approach during installation. Providing these values via external Kubernetes resources allows performing update (e.g. changing credentials) without having to rerun helm, and allows integration with other Kubernetes tooling (e.g. for Secret provisioning).

Standard connection settings like host, port and database name must be provided. Optionally, additional JDBC parameters can be specified.

values.yaml 
database:
  location: user-managed
  connection:
    host: database.example.com
    port: 5432
    databaseName: gradle_enterprise
    params: "?connectTimeout=60"

These can also be provided as a ConfigMap. The name of the ConfigMap must be provided, and the resource itself must be created prior to starting Gradle Enterprise.

values.yaml 
database:
  location: user-managed
  connection:
    configMapName: my-example-db-connection-details

The ConfigMap is then configured like this:

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-example-db-connection-details
data:
  host: database.example.com
  port: 5432
  dbname: gradle_enterprise
  jdbcParams: "?connectTimeout=60"

The port, dbname and jdbcParams properties are all optional. The default database name is gradle_enterprise.

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 Gradle Enterprise with connection details.

There are two options for credentials:

Option 1 - super user

If provided with credentials for a database superuser (such as the postgres user that is common on PostgreSQL database instances), Gradle Enterprise 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 Gradle Enterprise.

These credentials can also be supplied as a Kubernetes Secret:

values.yaml 
database:
  location: user-managed
  connection: ...
  credentials:
    superuser:
      secretName: my-example-db-superuser-credentials

The Secret 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=="
Option 2 - custom user

To set up your database without database superuser credentials, run the setup.sh script from the database setup scripts for your Gradle Enterprise 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 the user and provided to Gradle Enterprise via Helm configuration or Secrets.

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

These credentials can also be supplied as Secret resources. There are two accounts that must be configured, requiring a Secret each.

values.yaml 
database:
  location: user-managed
  connection: ...
  credentials:
    app:
      secretName: my-example-db-application-credentials
    migrator:
      secretName: my-example-db-migrator-credentials

In this example stringData is used (which does not require Base64 encoding) to show the correct usernames to use. The usernames are currently not configurable.

---
apiVersion: v1
kind: Secret
metadata:
  name: my-example-db-application-credentials
stringData:
  username: ge_app
  password: "app-example-password"

---
apiVersion: v1
kind: Secret
metadata:
  name: my-example-db-migrator-credentials
stringData:
  username: ge_migrator
  password: "migrator-example-password"

4. Storage Settings

Storage Class Configuration

The Kubernetes StorageClass can be configured for data, logs and backup volumes. If omitted, the default storage class for the cluster will be picked, if there is one. Please consult your cluster documentation for available storage classes.

Not all clusters provide a useable default storage class. It’s strongly recommended to consult your cluster documentation and select from the available storage classes explicitly.
values.yaml 
global:
  storage:
    data:
      class: some-provisioned-io-storage-class
    backup:
      class: slow-and-cheap-storage-class
    logs:
      class: general-purpose-storage-class
Backup storage class is not necessary when connecting to a user-managed database.

Storage Capacity Configuration

Gradle Enterprise needs a certain amount of storage for data, logs and backups. If omitted, the shown default amount of storage will be requested from the cluster.

values.yaml 
database:
  storage:
    data:
      capacity: 1000Gi # default 250Gi
    backup:
      capacity: 1000Gi # default 250Gi
buildCacheNode:
  storage:
    data:
      capacity: 100Gi # default 10Gi
enterprise:
  storage:
    logs:
      capacity: 500Mi # default 200Mi
metrics:
  storage:
    data:
      capacity: 1Gi # default 200Mi
testDistribution:
  storage:
    data:
      capacity: 20Gi # default 10Gi
monitoring:
  storage:
    data:
      capacity: 20Gi  # Default 20Gi
Backup storage capacity is not necessary when connecting to a user-managed database.

5. Routing Options

There are a number of ways to route web traffic to Gradle Enterprise from outside the Kubernetes cluster. These include:

Which you choose to use will depend on your organizational policies and available infrastructure.

Supplied Ingress

Gradle Enterprise can create a Kubernetes Ingress resource for you that is managed as part of your Helm release. The Ingress will be bound to the hostname that is configured.

values.yaml 
ingress:
  enabled: true
Your Ingress-Controller implementation has to be compatible with GRPC to support some Gradle Enterprise features (e.g. Bazel Build Scans). For more details about this, please consult your Ingress-Controller implementation.

User-managed Routing

For compatibility and configuration reasons, we strongly recommend to use the supplied Ingress definition. If the provided one is not suitable, you will need to provide your own configuration aligned with Gradle Enterprise supplied Ingress.

Gradle Enterprise creates a service named gradle-proxy exposing ports 80 and 443 (when HTTPS is enabled, see below) for accessing the application. This is the service to which alternative routing infrastructure such as load balancers will need to route traffic.

You may need to configure your Ingress differently to support Bazel using GRPC. Contact Gradle Enterprise Customer Support for help with Bazel and your own Ingress definition.

OpenShift Configuration

Gradle Enterprise needs to know when it is being deploying to an OpenShift cluster.

values.yaml 
global:
  openshiftInstallation: true

6. Networking Options

There are a number of considerations for Gradle Enterprise related to connectivity:

  • HTTP or HTTPS (with SSL certificates)

  • GRPC

  • Application Ports

  • Proxies

HTTP or HTTPs

Gradle Enterprise 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 Gradle Enterprise 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-----

Or the certificate can refer to a Kubernetes TLS Secret already available in the cluster:

values.yaml 
ingress:
  enabled: true
  ssl:
    secretName: example-ssl-certificate-secret-name
HTTPS SSL Certificate

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

Gradle Enterprise 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 Gradle Enterprise, 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, Gradle Enterprise 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 (see below). This may be the case if you use self-signed certificates or an internal certificate authority.

Additional Certificates

Additional trusted certificates for outbound traffic 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 configuration in a values file:

values.yaml 
global:
    unattended:
      configuration:
        version: 5
        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.

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

values.yaml 
global:
  hostname: ge.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

GRPC

Gradle Enterprise uses the GRPC protocol for Bazel features. To support this, the application has to be exposed with grpc/http2 compatible components (e.g. Ingress-Controller, Firewall, Load balancers…).

Please consult the documentation of those infrastructure or Kubernetes components to get more information about support and requirements for grpc compatibility. All examples below use example annotations that are not relevant for your installation.

GRPC with Ingress annotations

Some Ingress-Controller implementations require extra implementation-specific annotations on Ingress objects to be compatible with grpc. You can provide them using the following entry in the values.yaml:

values.yaml 
ingress:
  enabled: true
  grpc:
    annotations:
      acme.ingress.kubernetes.io/backend-protocol: "GRPC"
GRPC with Service annotations

Some Ingress-Controller implementations require extra implementation-specific annotations on Ingress objects to be compatible with grpc. You can provide them using the following entry in the values.yaml:

values.yaml 
ingress:
  enabled: true
  grpc:
    serviceAnnotations:
      acme.ingress.kubernetes.io/upstream-protocol.h2c: "grpc"

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, Gradle Enterprise 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.

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

values.yaml 
global:
    unattended:
      configuration:
        version: 5
        systemPassword: ...
        network:
         proxy:
           protocol: http (1)
           host: proxy.gradle.com (2)
           port: 8080 (3)
           excludedHosts: (4)
             - some.external
             - '*.internal'
           auth: (5)
             username: proxy_user
             password: "aes256:B0uVHRDhng+PraUI:2bOz71vKTexz0QH5:z7lO+1wOC/tA3izLAwV0BXMugg=="
1 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.
2 HTTP proxy host name.
3 HTTP proxy port, if no value is provided 80 will be used ad the default port.
4 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.
5 A username and password used to authenticate with the HTTP Proxy.

7. Unattended Configuration

Many aspects of Gradle Enterprise’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 Gradle Enterprise 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 Gradle Enterprise can be configured post-installation, there are two items that can and should be configured at installation time:

  • Proxy settings

  • S3 for Build Scans (AWS users only)

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 Gradle Enterprise Admin CLI must also be installed. Full instructions are available in the Administration Manual.

Having prepared a Gradle Enterprise configuration file and optionally an encryption key, you can provide it to Helm in one of two ways.

Example key:

gradle-enterprise-configuration.key 
aes256:B0uVHRDhng+PraUI:Aj25DOwJsrXnWYcprreHAS4l66k/7q5CIjFDg5PTR7U=

Example yaml file:

gradle-enterprise-configuration.yaml 
version: 6
systemPassword: "ObvvvqQww04Fn2jLBOOgjZDkXGL06fNmpueVcdk1lz0=:dBLNuLA/+qiwOqBQKf5pW89SV5mcQBJ4Vph/7lXerdD+2sLM8jij+2WJbBwXsqJ+mJugsveuUb+DyU3LBgkqcg=="
buildScans:
  keepDays: 30
email:
  administratorAddress: gradle-enterprise-adminstrator@example.com
  fromAddress: gradle-enterprise@example.com
  smtpServer: smtp.example.com:587
  sslProtocol: startTls
  authentication:
    type: login
    username: gradle-enterprise-adminstrator@example.com
    password: "aes256:B0uVHRDhng+PraUI:2bOz71vKTexz0QH5:z7lO+1wOC/tA3izLAwV0BXMugg=="

The file and encryption key can be provided inline in a Helm values file under the global.unattended property:

values.yaml 
global:
  unattended:
    key: "aes256:B0uVHRDhng+PraUI:Aj25DOwJsrXnWYcprreHAS4l66k/7q5CIjFDg5PTR7U=" (1)
    configuration: (2)
      version: 6
      systemPassword: "ObvvvqQww04Fn2jLBOOgjZDkXGL06fNmpueVcdk1lz0=:dBLNuLA/+qiwOqBQKf5pW89SV5mcQBJ4Vph/7lXerdD+2sLM8jij+2WJbBwXsqJ+mJugsveuUb+DyU3LBgkqcg=="
      buildScans:
        keepDays: 30
      email:
        administratorAddress: gradle-enterprise-adminstrator@example.com
        fromAddress: gradle-enterprise@example.com
        smtpServer: smtp.example.com:587
        sslProtocol: startTls
        authentication:
          type: login
          username: gradle-enterprise-adminstrator@example.com
          password: "aes256:B0uVHRDhng+PraUI:2bOz71vKTexz0QH5:z7lO+1wOC/tA3izLAwV0BXMugg=="
1 The encryption key used for any secrets in your configuration. In this example, the password for email authentication is encrypted. Not required if the configuration does not contain any encrypted passwords. Note that the systemPassword is a hashed value, not an encrypted one, and so does not require an encryption key.
2 The Gradle Enterprise configuration yaml is put inline underneath this property. Content needs to be indented such that it is all correctly under the global.unattended.configuration property.

Or they can be supplied as helm arguments using --set-file:

$ (helm command) \
    --set-file global.unattended.configuration=path/to/gradle-enterprise-configuration.yaml \
    --set-file global.unattended.key=path/to/gradle-enterprise-configuration.key
Gradle Enterprise configuration that is set in Helm like this will not be reapplied (i.e. overwrite manual changes made in the Admin UI) in subsequent installations unless the contents of the config file(s) has changed.

Proxy Settings

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

values.yaml 
global:
    unattended:
      configuration:
        version: 5 (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 config. See the Administration Manual.
2 The hashed system user 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.

S3 for Build Scans

To use your S3 bucket, add the following to your Helm values file:

values.yaml 
global:
  unattended:
    configuration:
      version: 7 (1)
      systemPassword: "«hashed-system-password»" (2)
      advanced:
        app:
          heapMemory: 5632 (3)
      buildScans:
        incomingStorageType: objectStorage
      objectStorage: (4)
        provider:
          type: s3
          bucket: example-bucket
          region: «region»
          credentials:
            source: environment
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. If you set incomingStoragetype to objectStorage, then you must configure an object storage service with this stanza in values.yaml for your Develocity instance.

This example uses S3 with environment-source credentials, but your object storage configuration may be different.

8. Airgap Installations

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

Appendix

Appendix A: Background Processing Configuration

Depending on the volume and frequency of your builds, background tasks for newly uploaded Build Scans can require a significant amount of CPU and memory. Moreover, some upgrades or configuration changes of Gradle Enterprise require reprocessing existing builds to extract new data. For example, when enabling Predictive Test Selection for the first time all existing builds will be processed to collect change and test execution history.

Therefore, background work can optionally be processed in a separate pod that can be scaled independently of other components to avoid any adverse effect on the Gradle Enterprise frontend. You should only enable background processing after being prompted by the Gradle Enterprise support team.

Enabling the background processor will increase hardware resource requirements. It also increases required number of database connections when a user managed database is used (80 connections ✖️ background processor replica count).
values.yaml 
enterpriseBackgroundProcessor:
  enabled: true
  scaling:
    replicas: 2

Appendix B: 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-2023.2/gradle-enterprise-standalone-values-2023.2.yaml
$ curl -L -o example.values.yaml.sha256 https://docs.gradle.com/enterprise/helm-standalone-installation/values-2023.2/gradle-enterprise-standalone-values-2023.2.yaml.sha256
$ echo "$(cat example.values.yaml.sha256)  example.values.yaml" | sha256sum -c

A direct download is available below:

Appendix C: Database Setup Scripts