Version 2023.1

This manual covers the installation of Gradle Enterprise into a single host. It is useful for administrators of Gradle Enterprise installations.

If your organisation has Kubernetes infrastructure or if you are familiar with Kubernetes and are comfortable operating a Kubernetes cluster, you may alternatively install Gradle Enterprise into an existing Kubernetes cluster.

Before installation

Installation Overview

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

The standalone installation of Gradle Enterprise described in this manual involves installing the K3s lightweight Kubernetes distribution onto a host, then using Helm to install and upgrade Gradle Enterprise in the K3s instance on that host.

Helm manages all Gradle Enterprise components, tracking what has been installed and upgrading them gracefully.

The helm command is used to install Gradle Enterprise into K3s and manages each installation / upgrade as a Helm release. See the Helm documentation for explanation of Helm concepts.

It is not necessary to have prior familiarity with Kubernetes concepts to install the Gradle Enterprise standalone distribution.

Database type

Gradle Enterprise can store data in either:

  • An embedded database that uses a local directory or volume to store its data, or

  • A user-managed database that is completely separate from Gradle Enterprise.

The two have different trade-offs. Please consider these prior to installation of Gradle Enterprise.

Embedded database

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

The embedded database has several advantages:

  • Simple setup: there is no other database to provision or configure.

  • The database will get upgraded in-place to the latest PostgreSQL version supported by Gradle Enterprise with the relevant Gradle Enterprise upgrade.

  • Gradle Enterprise features that need disk space usage information are supported.

  • For smaller installations it is often cheaper than using a separate database.

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

  • Disk I/O throughput can be a bottleneck to processing on a busy system. This can be difficult to tweak in many setups.

  • Backup management can get difficult past a certain database size. Specifically, backup generation can be slow and create load on the server, and managing backup files for a terabyte-sized database can be awkward.

  • There is no ability to keep a standby database available.

  • The database is a single point of failure. However, for single-node Gradle Enterprise installations any system outage will likely take the service down, regardless of the database.

User-managed database

A user-managed database can be any PostgreSQL 12, 13, or 14 compatible database, but the most common usage is a cloud-based database provider such as Amazon RDS or Aurora. These have a number of advantages, particularly in large installations:

  • Database systems need a different set of resources to be provisioned to run smoothly. For example, a high-traffic Gradle Enterprise instance processing a lot of Build Scans will need a lot of memory, but the database needs a lot of I/O throughput and CPU. Separating the database to a different system that can be scaled differently can allow more cost-effective resource allocation.

  • Most cloud-based database providers have tools that allow efficient snapshotting of databases, both manually and scheduled. This allows faster and more convenient backup and data management.

  • Many cloud database instances allow scaling of resources easily after an initial installation. This makes adding more storage or upgrading the instance type easier than changing the configuration of nodes that Gradle Enterprise is installed on.

  • It is possible to run standby databases for failover in the case of an outage. If self-hosting, this can be done using something like wal-e, and many cloud database providers have this functionality built in to the service.

  • Some cloud database providers have hot standby and failover functionality built in to the service.

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

  • Extra system(s) to provision and configure.

  • Administrator must ensure network connectivity to the cloud instance, and consider network latency when choosing where to set up a database.

  • Backups must be completely managed by the administrator or cloud database tool.

  • Disk space management and alerting must be completely managed by the administrator or cloud database tool. Gradle Enterprise features that allow certain actions at disk space percentage thresholds are not available.

  • There are extra security considerations such as credential cycling.

When Gradle Enterprise is using a user-managed database, customer support may not be able to assist with configuring the database for disaster recovery or restoring the database from a backup.

Build Scan storage

By default, Gradle Enterprise stores Build Scan data in the configured PostgreSQL database. This has the advantage of being simple to deploy and operate. It has the disadvantage of being expensive and difficult to scale for larger installations. Utilizing an additional S3-compatible store is a compelling deployment option for larger installations that produce large volumes of data.

Please see the Administration Manual for more details.

Installation requirements

This section outlines the installation resource requirements and configuration aspects that need to be resolved during installation.

Operating system requirements

We focus our support efforts on Ubuntu 18.04/20.04/22.04, RHEL 8.4/8.5/8.6, Debian 11, and Amazon Linux 2. Gradle Enterprise is expected to work on most modern Linux systems.

If you are using RHEL or CentOS, there are additional networking requirements for K3s.

K3s requirements

Networking

K3s needs several ports to be accessible from the host. Note that while these ports don’t need to be accessible from outside the host machine, K3s may access them using a different network interface or non-localhost IP.

Protocol Port

TCP

6443

TCP

10250

UDP

8472

For more details on K3s’s networking requirements, see K3s’s docs.

RHEL / CentOS

There are some additional requirements for RHEL or CentOS installations. You must disable the nm-cloud-setup.service and nm-cloud-setup.timer services.

Disabling firewalld is recommended, too. If you can’t, ensure that the ports mentioned above are accessible and enable IP address masquerading. This can be done with the following command:

$ firewall-cmd --add-masquerade --permanent
For more details on IP address masquerading, see RedHat’s docs.
For more details on the RHEL / CentOS requirements, see K3s’s docs.

CPU & memory requirements

The minimum installation requirements are:

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

  • 16 GB free RAM

For AWS EC2 users, the xlarge instance size provides 4 vCPU / 16 GiB Memory.

If you need to scale beyond a single node, we recommend instead following the Gradle Enterprise Kubernetes Helm Installation Manual.

Network connectivity requirements

Runtime network connectivity requirements

Gradle Enterprise can be run on hosts that can pull images from the internet, referred to as an online install in this guide, or on hosts without internet connectivity, referred to as an airgap install in this guide.

When starting, online installations of Gradle Enterprise will validate its license with Gradle over the internet. Once running, Gradle Enterprise will periodically check for license updates.

An online installation of Gradle Enterprise will not start if it cannot connect to both registry.gradle.com and harbor.gradle.com.

Airgap installations of Gradle Enterprise do not require internet connectivity when running (airgap installations do not validate the license on startup and do not periodically check for updates) and therefore do not require any special firewall rules. However, the airgap bundle used during installation must be downloaded from an internet-connected host. See Airgap installation for details.

Airgap installations require a specific entitlement on your license. If you need an airgap-enabled license, please contact your customer success representative.

Installation network connectivity requirements

Downloading the Gradle Enterprise Helm chart and container images requires internet access.

For online installations, Helm must be run on a host that has access to the internet.

For airgap installations:

  • The installation files must be downloaded on a host with access to the internet

  • Helm can be run on a host without access to the internet

  • There must be some mechanism for transferring the downloaded installation files to where they will be used

Network connectivity verification

See Verifying network connectivity for instructions on verifying network access prior to installation.

Storage requirements

By default, Gradle Enterprise stores its data in a database that is run as part of the application itself, with data being stored in a directory mounted on its host machine. We refer to this as the "embedded database". It is also possible to store most data in a user-managed database - see the below for details. Unless you specifically set this up, you will be using the embedded database.

Non-database requirements

In addition to the database, Gradle Enterprise needs some storage capacity for things like configuration files, logs, and build cache artifacts. These storage requirements apply regardless of which type of database you use, although the necessary size varies based on the database type.

Capacity

Gradle Enterprise stores the majority of its data in its “installation directory”, which defaults to /opt/gradle. The recommended minimum initial capacity to provide for this directory depends on which database type you use - see the database sections below for details. It is recommended to create a specific volume for the installation directory to avoid having another consume the space required for Gradle Enterprise, and to ensure at least 10% of the volume’s space is free at all times.

The amount of space used and rate of growth is dependent on your usage of Gradle Enterprise. See the disk space management section of the administration manual for information on avoiding running out of disk space for the installation directory.

The following are additional disk capacity requirements:

Location

/tmp

1 GB

/var/lib/rancher/k3s

30 GB

Performance
Disk performance has a significant impact on Gradle Enterprise.

For production workloads, storage volumes should exhibit SSD-class disk performance of at least 3000 input/output operations per second (IOPS). Most desktop-class, non-SSD disk drives do not provide this level of performance.

If you are experiencing performance problems, consider reviewing your Database type and Build Scan storage options. You can also contact Gradle support for advice.
Amazon Web Services

If you are using Amazon Web Services (AWS) and Elastic Block Storage (EBS) to host your Gradle Enterprise instance you should ensure that you provision 3,000 or more IOPS for the data volume. Keep in mind that some general purpose volumes (e.g. gp2) are limited to 3 IOPS per gigabyte, meaning that a 200 GB volume will only provide a maximum of 600 IOPS. If you are provisioning a volume smaller than 1TB you should consider using gp3 or a provisioned IOPS volume.

The recommendations above are based on average workloads. For projects with more complex builds or teams that produce a large number of build scans, Gradle Enterprise may require higher I/O performance than suggested.

Embedded database (default)

As explained above, by default, Gradle Enterprise stores its data in an embedded database instance. When doing so, the minimum capacity for the installation directory is 250 GB.

Backups

It is recommended to create backups of your Gradle Enterprise installation for disaster recovery purposes, by using Gradle Enterprise’s built-in backup scheduling. By default, backups are stored in the “backups” directory of the installation directory. To simplify disk space management, it is recommended to either mount a separate volume at this location or change this setting to a separate volume. The backup location can be specified at installation time, and changed later.

User-managed database

Gradle Enterprise can be configured to store data in a database that is hosted and managed separately from the rest of the application. This can help with performance in some circumstances by allowing database resources to be scaled separately to Gradle Enterprise. It can also simplify backups and volume management when using a database provider that provides tooling for these out of the box.

When using a user-managed database, the minimum capacity for the installation directory is 30 GB.

When using a user-managed database, some Gradle Enterprise administrative features such as automated backups and build scan disk space management features that respond to low disk space scenarios are not available.
Compatibility

Gradle Enterprise needs to connect to a PostgreSQL version 12, 13 or 14 compatible database.

Using PGBouncer with a user managed database is not supported. Gradle Enterprise uses and depends on PostgreSQL connection parameters that are not supported by PgBouncer.
Performance and capacity considerations

For similar workloads, Gradle Enterprise will need similar storage capacity and IOPS throughput as for the embedded database mentioned above. Please see your database provider’s options for provisioning and ensure that they meet these requirements.

When Gradle Enterprise and the database are not deployed in a private network near each other, consideration should also be given to ensuring that the database is hosted as close to the Gradle Enterprise host as possible. In a cloud provider this typically means deploying within the same availability zone or equivalent. This will ensure the lowest latency and highest throughput. Gradle Enterprise will not perform adequately under load if latency to its database is too high.

Backups

When using a user-managed database, backups must be handled by the database provider. Gradle Enterprise built-in backups will not operate in this mode.

Networking configuration

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

Proxy configuration

By default, Gradle Enterprise requires an internet connection to make several outbound HTTP requests (such as to validate its license) on startup. 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 at installation time via the unattended configuration mechanism, under the network section in the unattended configuration file.

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

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. Gradle Enterprise is connecting to very few external hosts, see the network connectivity section for more info.
5 A username and password used to authenticate with the HTTP Proxy.

Proxy configuration can also be configured after installation, see the Proxy configuration section of the administration guide. Proxy SSL certificates can be configured following HTTPS SSL certificate section.

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. This may be the case if you use self-signed certificates or an internal certificate authority.

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-seperated 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: 5
        systemPassword: ...
        network:
         additionalTrust: |
             -----BEGIN CERTIFICATE-----
             MIIDfzCCAmegAwIBAgIURqPslYGu7cHXs22q3RK6e5L87PwwDQYJKoZIhvcNAQEL
             ...
             s10yB5VjVBES6A22rYwYb8mImpQiVP/mr4ao5U5m+h50l3E=
             -----END CERTIFICATE-----
             -----BEGIN CERTIFICATE-----
             DSE3a3CCAmegAwIBAgIURqPslYGu7cHXs22q3RK6e5L87PwwDQYJKoZIhvcNAQEL
             ...
             s10yB5VjVBES6A22rYwYb8mImpQiVP/mr4ao5U5m+h50l3E=
             -----END CERTIFICATE-----

Additional trusted certificates can also be configured after installation, see the Untrusted SSL certificates section of the administration guide.

Helm configuration

Many aspects of Gradle Enterprise can be configured inside the application in the Administration screens. However, some things must be configured via Helm. These are typically things that are necessary to get Gradle Enterprise up and running and serving requests.

Prior to installing Gradle Enterprise, you will need to prepare a Helm values file and have your Gradle Enterprise license and SSL certificates (optional) available on the host where you are installing Gradle Enterprise.

Providing configuration to Helm

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.

Nested items in the values file have equivalents on the command line. So a values file with this content:

values.yaml
global:
  hostname: ge.example.com
database:
  type: embedded

is equivalent to passing --set global.hostname=ge.example.com --set database.type=embedded on the command line.

It is also possible to put more complex data into a Helm values file, such as a whole file:

values.yaml
global:
  license:
    file: |
      multi
      line
      content
      here

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

Example values file

Although the most commonly required configuration options are documented below, the example values file that can be found here and is included in the distribution has descriptions for all supported configuration options. After installing Helm and adding the Gradle Helm repository, this file can be viewed by running the following command:

$ helm show values gradle/gradle-enterprise-standalone

The output of this command can be redirected to a file to use as the starting point for your configuration:

$ helm show values gradle/gradle-enterprise-standalone > values.yaml

It’s also possible to see these values when installing from an airgap bundle. After downloading the bundle and transferring it to a host with Helm installed, extract and then run helm show values with the included chart:

$ helm show values gradle-enterprise-standalone-2023.1.5.tgz (1)
1 The file argument is a Helm chart archive as created by helm pull or extracted from an airgap bundle, not the airgap bundle itself.

Airgap configuration

In an airgap installation, the container images are preloaded into K3s. Helm is then configured so that no attempt is made to pull images from the outside world.

values.yaml
global:
  image:
    imagePullPolicy: Never

Gradle Enterprise license

You will have been provided with a Gradle Enterprise license file. This file can be used in any testing, staging or production deployments.

Your Gradle Enterprise license file must be provided to Helm. This can be done in a number of ways.

You can provide the file to helm using --set-file:

$ (helm command) --set-file global.license.file=path/to/gradle-enterprise.license

Alternatively, you can embed the file into your Helm values file:

values.yaml
global:
  license:
    file: |
      ====================== GRADLE ENTERPRISE LICENSE V1.0 ======================
      License file ID: YC3IWLASSXB5E
      Issued to: ACME Co.
      Issued at: 2022-02-11T05:11:38Z
      Expires at: 2023-02-11T00:00:00Z
      ============================================================================
      R0VMRgF4nBWOSZKCMAAAX+QUu3BUIJAIwUQiwsViEwMIDKOyvH701n3p6nJBYxoRHnAUnwHwKLjb
      YZMAbN8B5BMv3HaCdc9PbcG+Hkdz93XW+gsOY34jP+WC1iKC38SeCCKANn57HP7Bx/lVmFCLROHL
      Sv5hP4xlXO9kf40n35x4GgHhk5txTQQcMsmvG8Uz0W/hNN9eQlaMzsK8ZyKOSX0GsBN+dsp5Wq10
      /kVuf6u8LfUCPc72q79TWCvmFvNQD6RemcTxAbfILTNuaMsNgLjdCjYVK7padCLiolv2wc1P3pXF
      GoAExap9ZPKZTXpeaAaPeFF2qANCH/eXVW7+8kVxz0VH4PPnPjXc1yWzmHNTBu2WbpfDaSJil/g8
      lqB6zfaOvfSKQGkVMNthtqjJdSCmne3gWXpFJpGAe7dKkrD9K/vpoUZNUWuV7dFbFpqkNhJn+XAQ
      r2cjAak5TluR14aCsX6Fr4JgfSPyWNYdOB7DXrlnNT7d3p+/cFoqGVOvqjfDrnIkVBPLK5PCufU8
      VQzz/fagwC6dMtq0MEw5bphm5+LQeFPg/AOoua9P
      ====================== END GRADLE ENTERPRISE LICENSE =======================

It is also possible to specify the Gradle Enterprise license in its compact form, which is just the "data" part of the license.

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

This can be more convenient in some provisioning setups.

Hostname

As described above, a hostname for the application must be supplied:

values.yaml
global:
  hostname: ge.example.com

HTTPS

Connecting to the application over HTTPS is strongly recommended. 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 the built-in 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 can be provided inline in the Helm 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 supplied as helm arguments using --set-file:

$ (helm command) \
    --set-file ingress.ssl.cert=path/to/ssl.crt \
    --set-file ingress.ssl.key=path/to/ssl.key

HTTPS terminated externally

In many setups, a reverse proxy or load balancer will perform SSL termination. In these cases SSL certificates must be configured with that infrastructure.

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

Application ports

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

values.yaml
ingress:
  enabled: true
  port:
    http: 8080
    https: 8443

Storage configuration

The Gradle Enterprise standalone distribution will store its data in a specified directory. By default, this is /opt/gradle.

Logs and backups will be stored in subdirectories of that directory by default. These two locations can be set to something different, to allow logs and backups to be stored on different volumes.

values.yaml
global:
  storage:
    directory: /mnt/big-volume/ge           # Default /opt/gradle
    logs:
      directory: /var/log/gradle-enterprise # Default (global.storage.directory)/logs
    backup:
      directory: /mnt/vol2/ge-backups       # Default (global.storage.directory)/backups

Database configuration

By default, Gradle Enterprise will use an embedded database that stores its data in a local directory. In this configuration, there is nothing else to set up regarding the database.

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.

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"

The port and params properties are optional.

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. If provided with credentials for a database superuser (such as the postgres user that is common on PostgreSQL database instances), Gradle Enterprise can perform all further database setup, and can do so for all subsequent Gradle Enterprise upgrades. This is the recommended configuration.

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

Note that in some installations, and often in cloud-based databases, the typical credentials provided by the database provider are not a true superuser, but have many of the same abilities. For example, the supplied postgres account in Amazon RDS Postgres databases is not a true Postgres superuser but has the rds_superuser role. Such accounts are fine to configure Gradle Enterprise to use.

In some instances it may be preferable to not supply Gradle Enterprise with database superuser credentials. 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. When upgrading Gradle Enterprise, you will need to run the new version’s database setup script, too. The script will set up less privileged accounts for the application to use, and some privileged functions needed for the application to run.

Failing to run the database setup scripts before the upgrade may cause the application to not work after the upgrade.
You should stop the existing version of Gradle Enterprise before running the new version’s setup scripts.

The credentials for the accounts must then be set by the user and provided to Gradle Enterprise via Helm configuration.

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

Please contact Gradle support for assistance in running the script or questions about when to use non-superuser credentials.

Unattended application configuration

Many aspects of Gradle Enterprise’s behaviour can be configured via the Admin user interface. These are described in the Administration Manual.

It is possible to pre-configure Gradle Enterprise with the same settings that can be set via the Admin UI. This is useful to create a working Gradle Enterprise instance in a completely automated way, with no need to configure anything via a user interface.

The settings take the form of a yaml file. This file can be hand-written or exported from Gradle Enterprise. For more details on creating a Gradle Enterprise configuration yaml file, see Unattended configuration in the Administration Manual.

Making changes to the unattended configuration will overwrite any configuration changes made in the user interface. If you make configuration changes in the user interface, be sure to update your unattended configuration so that important settings are not lost the next time the unattended configuration is applied. See the Administration Manual for more details.

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

Unattended configuration of S3 Build Scan storage

If using S3 Build Scan storage, this can be configured as part of an unattended configuration. See the Administration Manual for more details.

Installation

As discussed in the network connectivity section, Gradle Enterprise supports two installation approaches.

At a high level, an online installation involves the following steps:

  1. Install K3s and Helm.

  2. Add and update the Gradle Helm repository.

  3. Create a Helm values file.

  4. Install Gradle Enterprise.

An airgap installation instead involves the following steps:

  1. Download necessary installation files.

  2. Create a Helm values file.

  3. Transfer files to where they will be used.

  4. Install K3s, Helm, and Gradle Enterprise.

Please see the following sections for details.

Online installation

If the host where you are installing Gradle Enterprise has internet connectivity, perform an online installation as described below.

1. Install K3s

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 ns

The expected output should be similar to this:

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

Install Helm:

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

Verify that helm is installed and working:

$ helm version

The expected output should be similar to this:

version.BuildInfo{Version:"v3.11.1", GitCommit:"293b50c65d4d56187cd4e2f390f0ada46b4c4737", GitTreeState:"clean", GoVersion:"go1.19.1"}

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

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

3. Install the gradle-enterprise-standalone Helm chart

Gradle Enterprise is distributed from the https://helm.gradle.com/ Helm repository.

Add the Gradle Enterprise 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 Gradle Enterprise chart is accessible:

$ helm search repo gradle-enterprise

This will report the latest versions available for the two Gradle Enterprise charts:

NAME                               	CHART VERSION	APP VERSION	DESCRIPTION
gradle/gradle-enterprise           	2023.1.5        2023.1.5    Official Gradle Enterprise chart for Kubernetes cluster installations
gradle/gradle-enterprise-standalone	2023.1.5        2023.1.5    Official Gradle Enterprise chart for standalone installations
This guide covers installation of the gradle-enterprise-standalone chart. Installation of the gradle-enterprise chart is covered in the Gradle Enterprise Helm Kubernetes Installation Manual.

4. Install Gradle Enterprise

Install Gradle Enterprise:

$ helm install \
    --create-namespace --namespace gradle-enterprise \
    ge-standalone \(1)
    gradle/gradle-enterprise-standalone \(2)
    --values values.yaml \(3)
    --set-file global.license.file=./gradle-enterprise.license (4)
1 This is the Helm release name. It is used by Helm to identify the Gradle Enterprise installation.
2 The Gradle Enterprise chart to install.
  • The name of the chart in the Gradle Helm chart repo - gradle/gradle-enterprise-standalone.

  • To install a specific version, pass this as additional parameters, e.g. --version 2023.1.5.

3 The Helm values file with configuration values, including items such as the hostname.
4 The Gradle Enterprise license file.

You may wish to pass other files using --set-file, such as certificates for HTTPS, or unattended configuration files.

Configuration values can be provided to Helm in a variety of ways. This includes:

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

  • providing files (such as the Gradle Enterprise license or certificates) with --set-file

  • setting individual values with --set

Choose a combination that works for your own configuration management processes.

Airgap installation

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

When installing Gradle Enterprise, follow the installation manual for that version as the steps may have changed. See Gradle Enterprise releases for information about the available versions.

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

$ mkdir gradle-enterprise-installation-files && cd gradle-enterprise-installation-files

1. Download K3s

Download and verify the K3s images, binary, and install script:

$ curl -LO https://github.com/k3s-io/k3s/releases/download/v1.25.6+k3s1/k3s-airgap-images-amd64.tar.gz
$ curl -LO https://github.com/k3s-io/k3s/releases/download/v1.25.6+k3s1/k3s
$ curl -L -o install_k3s.sh https://get.k3s.io
$ echo "6d41ae24985061f6fcfd80bad1162ab39cfd40308f68956f22794be816b0245f  k3s" | \
    sha256sum -c
$ echo "6e5f11b00586df7ea517d996c5a26637c4c99f869cb42296ccaccaff59e7df96  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

2. Download Helm

Download and verify the Helm binary:

$ curl -L -o helm-linux-amd64.tar.gz https://get.helm.sh/helm-v3.11.1-linux-amd64.tar.gz
$ echo "0b1be96b66fab4770526f136f5f1a385a47c41923d33aab0dcb500e0f6c1bf7c  helm-linux-amd64.tar.gz" | \
    sha256sum -c

3. Download bundle

Save your Gradle Enterprise license to the transfer directory as “gradle-enterprise.license”.

Download and verify the airgap bundle:

$ curl -LOJd @gradle-enterprise.license \
    https://registry.gradle.com/airgap/gradle-enterprise-standalone-2023.1.5-bundle.tar.gz
$ curl -LOJd @gradle-enterprise.license \
    https://registry.gradle.com/airgap/gradle-enterprise-standalone-2023.1.5-bundle.tar.gz.sha256
$ sha256sum -c gradle-enterprise-standalone-2023.1.5-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 in your browser and following the instructions on the page.

4. Download example Helm values file

Download and verify the example Helm values file:

$ curl -L -o example.values.yaml \
    https://docs.gradle.com/enterprise/helm-standalone-installation/values-2023.1/gradle-enterprise-standalone-values-2023.1.yaml
$ curl -L -o example.values.yaml.sha256 \
    https://docs.gradle.com/enterprise/helm-standalone-installation/values-2023.1/gradle-enterprise-standalone-values-2023.1.yaml.sha256
$ echo "$(cat example.values.yaml.sha256)  example.values.yaml" | sha256sum -c

5. Configure Helm values file

Before installing Gradle Enterprise and its prerequisites, we recommend creating your Helm values file on your local workstation (where you can use your favorite text editor). Copy “example.values.yaml” to “values.yaml”, review the available settings, and modify as needed.

6. Transfer files

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

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

  • k3s

  • install_k3s.sh

  • k3s-selinux.el8.noarch.rpm (only if you are running SELinux)

  • helm-linux-amd64.tar.gz

  • gradle-enterprise.license

  • values.yaml

  • gradle-enterprise-standalone-2023.1.5-bundle.tar.gz

  • Optional: SSL certificates

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

7. Install K3s

Follow these instructions on the host where you are installing Gradle Enterprise 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 ns

    The expected output should be similar to this:

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

8. Install Helm

Follow these instructions on the host where you are installing Gradle Enterprise 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

Verify that helm is installed and working:

$ helm version

The expected output should be similar to this:

version.BuildInfo{Version:"v3.11.1", GitCommit:"293b50c65d4d56187cd4e2f390f0ada46b4c4737", GitTreeState:"clean", GoVersion:"go1.19.1"}

9. Install Gradle Enterprise

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

Install Gradle Enterprise:

$ tar zxvf gradle-enterprise-standalone-2023.1.5-bundle.tar.gz
$ k3s ctr images import gradle-enterprise-standalone-2023.1.5-images.tar (1)
$ helm install \
    --create-namespace --namespace gradle-enterprise \
    ge-standalone \(2)
    gradle-enterprise-standalone-2023.1.5.tgz \
    --values values.yaml \(3)
    --set-file global.license.file=./gradle-enterprise.license (4)
1 This command imports the images into K3s.
2 This is the Helm release name. It is used by Helm to identify the Gradle Enterprise installation.
3 The Helm values file with configuration values, including items such as the hostname.
4 The Gradle Enterprise license file.

You may wish to pass other files using --set-file, such as certificates for HTTPS, or unattended configuration files.

Configuration values can be provided to Helm in a variety of ways. This includes:

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

  • providing files (such as the Gradle Enterprise license or certificates) with --set-file

  • setting individual values with --set

Choose a combination that works for your own configuration management processes.

Post-installation

System check

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

$ helm --namespace gradle-enterprise list
NAME         	NAMESPACE        	REVISION	UPDATED                                	STATUS  	CHART                                	APP VERSION
ge-standalone	gradle-enterprise	1       	2023-05-30 03:01:58.704019291 +0000 UTC	deployed	gradle-enterprise-standalone-2023.1.5  	2023.1.5

You can inspect the status of the Gradle Enterprise pods:

$ kubectl --namespace gradle-enterprise get pods
NAME                                               READY   STATUS    RESTARTS   AGE
gradle-enterprise-operator-76694c949d-md5dh        1/1     Running   0          84m
gradle-proxy-0                                     1/1     Running   0          83m
gradle-database-65d975cf8-dk7kw                    2/2     Running   0          83m
gradle-enterprise-app-0                            1/1     Running   0          83m
gradle-metrics-cfcd8f7f7-zqds9                     1/1     Running   0          83m
gradle-test-distribution-broker-6fd84c6988-x6jvw   1/1     Running   0          83m
gradle-build-cache-node-57b9bdd46d-2txf5           1/1     Running   0          84m
gradle-keycloak-0                                  1/1     Running   0          83m

Verifying network connectivity to Gradle Enterprise

Gradle Enterprise has a /ping endpoint, which can be used to verify network connectivity with Gradle Enterprise.

Connectivity to Gradle Enterprise installation can be tested by running the following command on hosts / computers which need to connect to Gradle Enterprise:

$ curl -sw \\n --fail-with-body --show-error https://«gradle-enterprise-host»/ping

It should return SUCCESS.

Cleanup

For airgap installations, it is recommended to remove the following files after installation:

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

  • k3s

  • install_k3s.sh

  • k3s-selinux.el8.noarch.rpm

  • helm-linux-amd64.tar.gz

  • gradle-enterprise-standalone-2023.1.5-bundle.tar.gz

  • gradle-enterprise-standalone-2023.1.5.tgz

  • gradle-enterprise-standalone-2023.1.5-images.tar

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

  • Gradle Enterprise license

Care should be applied when handling these files as they may be considered sensitive.

Post-installation setup

It is strongly recommended to immediately change the system user password from its default after installation to secure your installation.

A number of settings should be reviewed after installation. Please refer to the administration manual.

Upgrading

Before upgrading, be sure to check the upgrade notes section for any special considerations when upgrading from older versions of Gradle Enterprise.

Gradle Enterprise upgrades irreversibly update the database schema. This means that upgrades are irreversible unless the database is restored from a backup. As such, we strongly recommend users take a database backup before upgrading, and be prepared to restore it if the upgrade encounters a critical issue.

To upgrade K3s, Helm, and Gradle Enterprise, follow the same procedure as for an initial installation. However, there are some notes to consider:

  • Run helm repo update gradle to update locally available charts.

  • Run helm upgrade instead of helm install.

  • Use the same Helm release name (ge-standalone in the examples in this guide).

  • When running a helm upgrade, Helm will reuse values that were previously used. This means that you can run:

    $ helm upgrade \
        --namespace gradle-enterprise \
        --reuse-values \
        ge-standalone gradle/gradle-enterprise-standalone

    or for airgap installations:

    $ helm upgrade \
        --namespace gradle-enterprise \
        --reuse-values \
        ge-standalone gradle-enterprise-standalone-2023.1.5.tgz

    and not need to specify any values. If you do specify some changed values (for example, to use a new license file), they will be merged with your previous values.

  • Alternatively, 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.
  • For major version upgrades (e.g. 2021.2.4 to 2021.3 or later), if data is stored in a user-managed database and superuser credentials are not supplied, the database setup script must be run prior to the upgrade. The correct script for the major version to which the system is being upgraded can be downloaded from the appendix.

Changing configuration values

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

To check the currently deployed version, run:

$ helm history --namespace gradle-enterprise ge-standalone --max 1

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

$ helm upgrade \
    --namespace gradle-enterprise \
    ge-standalone gradle/gradle-enterprise-standalone \
    --version «deployed-version»
    --reuse-values
    «new values options»

or for a Helm-managed airgap installation:

$ helm upgrade \
    --namespace gradle-enterprise \
    ge-standalone gradle-enterprise-standalone-2023.1.5.tgz \
    --version «deployed-version»
    --reuse-values
    «new values options»

The above examples reuse previous values by default. Any specified values will override the existing values. Alternatively, if you wish 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 can be provided to Helm in a variety of ways. This includes:

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

  • providing files (such as the Gradle Enterprise license or certificates) with --set-file

  • setting individual values with --set

Choose a combination that works for your own configuration management processes.

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.

Uninstalling

For Helm-managed installations, Gradle Enterprise can be uninstalled by running helm uninstall «your-release-name»:

Example:

$ helm uninstall --namespace gradle-enterprise ge-standalone

Troubleshooting

K3s installation

If you are having difficulty with installing K3s, first review the following:

Support

If you are experiencing issues with Gradle Enterprise, please see the Administration Manual for information about how to submit a support ticket.

Appendix A: Upgrade notes

Gradle Enterprise 2023.1 long startup time

Gradle Enterprise 2023.1 had an issue that can result in a very long first startup time after upgrade for some installations. It is strongly recommended that customers who have not yet upgraded to 2023.1 instead upgrade directly to 2023.1.1 or later.

Build Cache Node and Test Distribution Agent now require a Java 17 runtime

The required runtime version of Java has changed from 11 to 17 in this release for both the Build Cache Node and the Test Distribution Agent. If you are currently using their JAR distribution, please install a Java 17 compatible runtime environment on your server. In the interim, you can continue to use older versions to connect to Gradle Enterprise.

For the Test Distribution Agent Docker image, the bundled JDK is used to run the agent process itself and to fork JVMs to execute tests. Therefore, if you are relying on the JDK 11 version provided by the image to execute tests, please follow the instructions in the documentation to build a custom image that also contains JDK 11.

Deprecation of pre-2021.3 versions of Test Distribution Agent, Test Distribution Gradle Plugin, and Gradle Enterprise Maven Extension (for use with Test Distribution)

Using Test Distribution with versions older than Test Distribution Gradle plugin 2.2, Gradle Enterprise Maven extension 1.11, or Test Distribution agent 1.6 is now deprecated. These versions were introduced before Gradle Enterprise 2021.3 and use a communication protocol that requires manually specifying JVM arguments on JDK 17 and later. Therefore, support for them will be removed in 2023.2. Please check your builds and agents and update them as necessary.

The maximum number of build cache entries may reduce after upgrading

Internal changes to the build cache service now require more disk space for internal bookkeeping, leaving less room for build cache entries. The degree of the change depends on the number of entries stored in the cache. Caches with a million entries or more may experience a reduction in available disk space for cache entries by up to 2GiB, which is expected to have a negligible impact on build cache effectiveness.

Deprecation of anonymous access to build cache configuration

Allowing anonymous access to the “Configure build caches” permission (formerly known as “Build cache admin” in earlier versions of Gradle Enterprise) is deprecated. It will be removed in future versions of Gradle Enterprise.

Backups created by Gradle Enterprise 2019.2 or earlier can no longer be restored directly

Backups made using Gradle Enterprise 2019.2 or earlier cannot be restored directly to an installation of Gradle Enterprise 2023.1 (or later). Backups from any version after 2019.2 may still be restored directly to a Gradle Enterprise 2023.1 installation.

To restore a backup from Gradle Enterprise 2019.2 or earlier to a Gradle Enterprise 2023.1 installation, you will first need to restore to a pre 2023.1 version and then either upgrade that installation or create a backup of that installation and restore it to a 2023.1 installation.

Appendix B: Verifying network connectivity

For installation/upgrades of online installations, internet connectivity to https://helm.gradle.com is required.

Online installations require runtime internet connectivity to https://registry.gradle.com and https://harbor.gradle.com.

Connectivity to these can be tested by running the following commands on the host where you are installing Gradle Enterprise:

$ curl -sw \\n --fail-with-body --show-error https://helm.gradle.com/ping
$ curl -sw \\n --fail-with-body --show-error https://registry.gradle.com/ping
$ curl -sw \\n --fail-with-body --show-error https://harbor.gradle.com/ping

All should return SUCCESS.

If any errors occur, please review your network setup before installing or upgrading Gradle Enterprise.

Appendix C: Example Helm values file

Appendix D: Database setup scripts