This manual covers the installation and operation of Gradle Enterprise. It is useful for administrators and maintainers of Gradle Enterprise installations, and build engineers that maintain or develop Gradle builds that leverage Gradle Enterprise. If you’re interested on deploying Gradle Enterprise into your own Kubernetes cluster, jump into these specific instructions.

Installation and operation

Gradle Enterprise leverages Replicated for installation, configuration and software updates. Replicated orchestrates downloading and installing the Gradle Enterprise application on the host system as well as checking for periodic updates.

Replicated, as well as the Gradle Enterprise application both run on the host in the form of Docker containers. Management of these containers is done transparently by Replicated, however regular Docker commands can be used to inspect the status of running containers.

While the regular docker commands can be used to manage Gradle Enterprise application containers, it is highly recommended that maintenance actions such as starting and stopping the application be done via the Replicated admin console.

Before you install

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

Supported operating systems

Server versions of the following Linux distributions are supported:

  • Debian 7.7+

  • Ubuntu 14.04 / 16.04

  • Fedora 21 / 22

  • Red Hat Enterprise Linux 6.5+

  • CentOS 6+

  • Amazon Linux 2014.03 / 2014.09 / 2015.03 / 2015.09 / 2016.03 / 2016.09 / 2017.03 / 2017.09

  • Amazon Linux 2

  • Oracle Linux 6.5+

  • SUSE Enterprise Linux 12

The host system must support docker-engine (1.7.1+) which requires a 64-bit distribution with a kernel minimum of 3.10. For detailed requirements and installation guides see the docker installation docs.

Installing on non-Linux systems

Gradle Enterprise requires a modern Linux operating system with Docker support. For trial and evaluation purposes, you can use a virtual machine to perform the installation on a non-Linux system. Several desktop virtual machine providers, such as VirtualBox, exist for this purpose.

Virtualized installation considerations

Some considerations when using virtualization in conjunction with Gradle Enterprise are:

  • Any of the above listed Linux distributions will still work, even in a virtualized environment.

  • You will need to forward the necessary ports to the host system in order to configure Gradle Enterprise and access the application.

    Newer versions of MacOS may have built-in services listening on these ports, in particular, port 8800. If you encounter errors binding to these ports you may need to forward them to a different port on your host.
  • When using a virtual machine provider such as VirtualBox, the IP of your virtualized environment will differ depending on how you have configured networking for the virtual machine. For example, with VirtualBox, if you have set it up with the default networking mode (NAT), then the IP address of the Gradle Enterprise installation will be the same as that of your host system.

    When running in NAT networking mode, a VirtualBox machine will not be able to communicate with a service running on the host system. This has the implication that a virtualized Gradle Enterprise installation will not be able to communicate with a remote build cache node running on the same host as the VirtualBox instance. For this, you will need to investigate a different network mode (such as Host-only), or you will need to install the build cache node on a different host within your organization.
  • If you remap the ports 80 or 443 of your virtual machine, you will need to ensure that the Gradle Enterprise ports are reconfigured to match on the Settings page of the admin console. Failing to do this will cause some areas of the Gradle Enterprise UI to go to an incorrect address, and the server will generate an incorrect URL for build scans.

  • Gradle Enterprise can consume a considerable amount of disk space depending on how actively it is used. Keep this in mind when provisioning a virtual disk. Also, depending on the virtualization method used, disk performance may not be consistent with native disk access so Gradle Enterprise performance is likely to be affected.

Using desktop virtualization software such as VirtualBox or Vagrant is not recommended for production deployments.

Storage requirements

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 is 250 GB.

The amount of space used and rate of growth is dependent on your usage of Gradle Enterprise. See the managing disk usage section for how to avoid running out of disk space for the installation directory.

The following are additional disk capacity requirements:

Location

/tmp

1 GB

/var/lib/docker

30 GB

/var/lib/replicated

250 MB

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.

You can run the following benchmark to estimate your disk performance:

docker run --rm -v /opt/gradle/fs-test:/var/lib/postgresql/data postgres pg_test_fsync

The majority of reported results should indicate greater than 3000 ops/sec.

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 3000 or more IOPS for the data volume. Keep in mind that general purpose (or gp2) volumes are limited to 3 IOPS per gigabyte, meaning that 200 GB volume will only provide a maximum of 600 IOPS. If you are provisioning a volume smaller than 2TB you should consider using a provisioned IOPS (or io1) 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.

CPU & memory requirements

  • Quad-core 2GHz or better CPU

  • 8 GB free RAM

Networking configuration

The following TCP ports on the host system are used by the application:

Port Interface Required Description

9870-9880

Public

Always

Replicated Operator

8800

Public

Always

System admin console

9900

Public

Always

Graphite console

443

Public

When SSL is enabled (default)

HTTPS port used to access the application

80

Public

When SSL is disabled

HTTP port used to access the application

8080-8081

docker0

Always

Build scans and build cache servers

5432

docker0

Always

PostgreSQL database

Firewall and proxy configuration

In addition to the ports listed above the host system will also need access to the internet for retrieving application images, syncing license information, etc. Depending on your firewall or proxy configuration you may need to whitelist individual websites. Please refer to this document for detailed information on all external websites necessary for installation and proper system function.

If external network access is not possible you can still install Gradle Enterprise via an airgapped installation.

Application hostname

When installing Gradle Enterprise, you will be asked to provide a hostname. This should be the hostname that users of the installation use to access it and therefore should resolve within your network.

This value can be changed later.

If you are unsure what name to assign, or you do not yet have a hostname assigned, you can use the public IP address of the server, or localhost if you only intend to access the installation from the same host for the time being.

The public IP address is the IP address you would use to SSH on to the host system.

SSL certificate

It is strongly recommended that production installations of Gradle Enterprise are configured to use HTTPS, with a trusted certificate. This requires ownership of a certificate for the public hostname you intend to use that was issued by a trusted certificate authority.

If you do not have a certificate to use you may either:

  1. Allow Gradle Enterprise to generate an untrusted, self-signed, certificate

  2. Disable HTTPS and use plain HTTP

Using an untrusted certificate requires extra build script configuration for both build scans and the build cache, in addition to requiring users to accept the untrusted connection in their browser each time they access the application. However, your data will be encrypted whilst in transit on the network.

Using plain HTTP means that no extra build or browser configuration is required, but your data will not be encrypted while in transit on the network.

Whilst it is possible to run Gradle Enterprise unsecured over HTTP, the Replicated admin console must be run over HTTPS.

For trial installations, using plain HTTP is generally OK and preferable to using a self-signed certificate. It is strongly discouraged for production installations however.

Installation

Gradle Enterprise supports multiple installation mechanisms.

Standard installation is recommended as it is simple and requires few steps. It requires the host system to have Internet access.

Once installed, Gradle Enterprise does not require a connection to the Internet. It is possible to only establish an Internet connection for the host system for the initial install and to obtain subsequent updates manually.

Airgapped installation can be performed on a host without an Internet connection. Installation materials are downloaded from a system with Internet access and then manually transferred to the host system.

Some non-essential Gradle Enterprise functions may not be available when operating without an Internet connection.

Airgapped installations are not available for trial licenses.

Standard

Installing the admin console
  1. During installation you will be asked for any required proxy settings. You should have this information on hand before proceeding with the next step. Later you may also be prompted to supply the host’s public IP address if the installer was unable to automatically detect it. If this happens, the IP address should be left blank.

    If you intend to run the Gradle Enterprise application with SSL enabled (which is recommended) you should also have the public certificate and private key available prior to beginning installation.

  2. Install Replicated on the target host by issuing the following command on the host system.

    curl -sSL https://get.replicated.com/docker/gradleenterprise/stable | sudo bash
    As part of the installation procedure, Replicated will create a user replicated (if one doesn’t exist already), and add it to the docker group of users.
  3. Open a web browser and navigate to https://«hostname»:8800 to access the admin console.

  4. Enter a valid Hostname used by the admin console. This name should be routable on your network and resolve to the IP address of the host system. It will be used when generating self-signed certificates for the admin console.

  5. For SSL used by the admin console you can either use self-signed certificates or provide your own.

    1. To use self-signed certificates simply select Use Self-Signed Cert.

    2. To provide your own certificates provide files for Private Key and Certificate and select Upload & Continue.

    install ssl 2017.7
    These settings can always be changed later via the Console Settings screen, accessible under the install gear icon icon in the upper-right corner of the admin console.
  6. Select Choose License and navigate to the location of the license file which was sent to you via email.

    install license 2017.7
  7. Choose a method for securing the admin console. Either Anonymous or Password, and select Continue.

    install password 2018.3
    Should you choose to change these settings later, you can do so by visiting https://«hostname»:8800/create-password.
  8. The system will perform some pre-flight checks to test the host system for compatibility. Although the software can be installed without passing these checks it is highly recommended that any deficiencies be addressed. Proper system functionality cannot be guaranteed if the host system does not meet the required criteria.

    install preflight check 2017.7

    Select Continue.

After installing the admin console the application will begin downloading in the background. When the download is complete installation will begin automatically. At any time you can select Dashboard from the navigation menu to see the current status of the application.

You will be presented with a screen to allow you to customize various application settings. Changes to these settings can be made at any time. Changes will only take effect after selecting Save on the bottom of the Settings page.

Selecting Save will require the application to restart for changes to take effect. Select Restart Now to restart the application and apply the new settings. If the application is in the process of starting (during initial installation) then changes will be applied when the application finishes starting. Changes to a stopped application will apply the next time the application is started.
Upgrading

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

  1. Open a web browser and navigate to https://«hostname»:8800 to access the admin console.

  2. Checks for updates are done periodically. When an update is available you will see something similar to the screen below. You can explicitly check for updates at any time by selecting Check Now.

    update dashboard 2018.2
  3. Select View Update.

  4. On the Release History screen select Install Update to install the latest released version.

    Updating requires the application to be temporarily shutdown. This means the application will not be accessible and information for builds run during this downtime period will not be captured.
    update install 2017.7
  5. The updated application images will be downloaded and installation will begin immediately once the download has completed.

  6. Select Dashboard from the navigation menu. The status Started will be shown when installation is complete and the application is up and running.

    update started 2017.7

After upgrading, Docker may keep older Gradle Enterprise images on disk. These unused images can consume a significant amount of disk space. You can clear up space taken by unused Docker images at any time by running the following command:

docker images --filter dangling=true -q | xargs docker rmi

Airgapped

Installation

In an airgapped installation, you will need to first install Docker on the host system, since the automated installer will not install it for you. You can refer to this guide for information about installing Docker in an airgapped fashion. After a compatible version of Docker is installed, follow the instructions below.

  1. Along with your provided license file you will be given a link and password to access the Gradle Enterprise airgap bundle download page.

  2. Select Get Download Link and download the airgap bundle.

    If using wget to download the airgap bundle you will need to use the --trust-server-names option or rename the downloaded file to .airgap. You may also need to surround the URL with quotes (").
  3. Transfer the airgap bundle to the host system.

  4. Download the admin console installer from https://s3.amazonaws.com/replicated-airgap-work/replicated.tar.gz.

  5. Transfer the installer bundle to the host system.

  6. Run the admin console installer.

    tar xzvf replicated.tar.gz
    cat ./install.sh | sudo bash -s airgap
  7. Open a web browser and navigate to https://«hostname»:8800 to access the admin console.

  8. Enter a valid Hostname used by the admin console. This name should be routable on your network and resolve to the IP address of the host system. It will be used when generating self-signed certificates for the admin console.

  9. For SSL used by the admin console you can either use self-signed certificates or provide your own.

    1. To use self-signed certificates simply select Use Self-Signed Cert.

    2. To provide your own certificates provide files for Private Key and Certificate and select Upload & Continue.

    install ssl airgap 2017.7
    These settings can always be changed later via the Console Settings screen, accessible under the install gear icon icon in the upper-right corner of the admin console.
  10. At the following screen, select Choose license and select the license file which was sent to you via email.

    install license airgap 2017.7
  11. Then on the next screen choose Airgapped and click Continue

    install choose installation airgap 2017.7
  12. Enter the location of the .airgap file you downloaded and transferred earlier.

    install airgap package 2017.7
  13. Select Continue.

  14. After the airgap packages have been extracted, choose a method for securing the admin console. Either Anonymous or Password, and select Continue.

    install password 2018.3
    Should you choose to change these settings later, you can do so by visiting https://«hostname»:8800/create-password.
  15. The system will perform some pre-flight checks to test the host system for compatibility. Although the software can be installed without passing these checks it is highly recommended that any deficiencies be addressed. Proper system functionality cannot be guaranteed if the host system does not meet the required criteria.

    install preflight check 2017.7

    Select Continue.

You will be presented with a screen to allow you to customize various application settings. Changes to these settings can be made at any time. Changes will only take effect after selecting Save on the bottom of the Settings page.

Selecting Save will require the application to restart for changes to take effect. Select Restart Now to restart the application and apply the new settings. If the application is in the process of starting (during intial installation) then changes will be applied when the application finishes starting. Changes to a stopped application will apply the next time the application is started.
Upgrading
  1. Confirm the update path used to search for new airgap bundles. The admin console will look for updates in this folder. You can configure this in the Airgap Settings settings section of the Console Settings page which is accessible via the install gear icon in the navigation menu.

    update airgap 2017.7
  2. Follow steps 1-3 in the Installation section above to get the latest airgap bundle. You will want to place the .airgap file in the location confirmed in the step above.

  3. You can now upgrade the system using the instructions in the Upgrading section.

Managing disk usage

Gradle Enterprise stores the majority of its data in its “installation directory”, which defaults to /opt/gradle. The amount of space used and rate of growth is dependent on your usage of Gradle Enterprise. Administrators should take care to ensure that the volume this directory is on does not run out of space.

Monitoring

The admin console graphs the usage of the disk volume that contains the installation directory, over the last 30 days. It is strongly recommended to regularly verify that adequate disk space is available and will be available in the future.

disk usage

Alternatively, or in conjunction with, it is recommended to use a server monitoring solution to notify when free space is running low on the installation volume.

Build scan retention

For most installations, disk usage will be dominated by build scan data. The amount of data used and rate of growth is dependent on the number and size of builds being captured. By default, build scans are stored indefinitely.

To limit the amount of disk space used to store build scan data, enable the “Delete old build scans” option in the admin console. Each day, build scans for builds that occurred more than the specified number of days ago will be deleted.

delete old build scans
Due to a current technical restriction, deleting old build scans does not increase the amount of free disk space. Instead, disk space previously used to store build scans that have since been deleted is used for new build scans. Enabling deletion of old build scans will slow or stop the growth rate, but not reduce the amount of used space. This restriction will be removed in a future version of Gradle Enterprise.

Backup and disaster recovery

Gradle Enterprise provides system backup and restore capabilities to facilitate disaster recovery. Backups can be triggered manually or scheduled to be done automatically on a periodic basis, and require no system downtime.

The backup process produces a single compressed archive which can be used to restore all user data to a state at the time of the backup. It is highly recommended that this archive additionally be copied to an off-host location, in the case of a complete loss of the host system or volume used to store backup archives.

In addition to disaster recovery, backup archives can be used to migrate your Gradle Enterprise data to a new host system. This can be useful in scenarios where a trial instance is promoted to a production one or in the event that you require upgrading your Gradle Enterprise instance hardware.

Only user data is captured in each backup. Admin console settings, including SSL certificates, passwords, etc are not included in backup archives. We suggest making a note of such configuration options, to be used during the restore process in case of a complete loss of the system.

Creating backups

Backup settings can be configured on the Settings page of the admin console under the Backup section. The storage location of backup archives can be customized, as well as retention policies and email notifications which apply to both automatic and manual backups. You can additionally configure Gradle Enterprise to automatically perform backups on a regular schedule, either daily, weekly or via a custom schedule defined as a cron expression.

Manual backups

In addition to configuring automatic scheduled backups, you may trigger a manual backup at any time by running the following command on the host system.

replicated admin backup
Tracking backup runtime

For instances with a large number of build scans, a backup may take an extended amount of time. Backup logs, as well as email notifications will include the time taken to perform the backup. In addition to inspecting logs, the Dashboard page of the admin console includes a graph of backup runtimes for the past 30 days.

backup runtime

Restoring from a backup

Once a backup archive is created you may use it to restore a Gradle Enterprise instance to the backup state at any time. Backup archives contain only a copy of the application database and not configuration settings entered in the admin console. If restoring to a completely new host you will first need to perform a fresh installation and restore any configuration options manually.

Executing the restore_snapshot.sh script requires 7zip to be installed on the host system. This can typically be done by installing the p7zip package using your Linux distribution’s package manager.
  1. If restoring to a new host, perform a fresh installation as described in the Installation section above.

  2. Copy the previously created backup archive to a location on the host system.

  3. Stop the server by visiting the Dashboard page of the admin console and selecting Stop Now.

  4. Execute the following command on the host system as root.

    /opt/gradle/tools/restore_snapshot.sh \
        /opt/gradle/data/backups/backup.7z # location of backup archive
  5. When the script has completed, return to the admin console Dashboard and select Start Now.

Troubleshooting

Issues with the admin console

If you experience difficulty accessing the admin console then you may need to restart the Replicated services on the host system. To restart Replicated, issue the following commands:

Debian/Ubuntu
sudo service replicated restart
sudo service replicated-ui restart
sudo service replicated-operator restart
CentOS 7/RHEL 7/Fedora
sudo systemctl restart replicated replicated-ui replicated-operator

Resource usage

Standard Linux process utilities such as ps and top can be used to inspect the resource usage of the application.

Both Replicated and the application run in Docker containers. The following is sample output from running the command ps -aufx which displays the application’s processes.

process list

The admin console (https://«hostname»:8800/dashboard) also displays CPU and memory usage of the application’s Docker containers.

dashboard resource usage 2017.7
Both the Memory Usage and CPU Usage charts have a window of 15 minutes and are representative of the most recent usage data.

Alternatively, docker stats can be used to get more detailed resource usage information about the individual Docker containers.

docker stats

Support

If you are experiencing issues with Gradle Enterprise or the build scan plugin please submit a support ticket at support.gradle.com, including details of the issue and an attached Support Bundle.

Support Bundles assist our engineers in troubleshooting your issue by providing the following information about your Gradle Enterprise installation:

  • Host Information

    • Operating System

    • CPU

    • Memory

    • Disk Usage

  • Logs

    • Gradle Enterprise

    • Replicated

  • Docker Configuration

  • Gradle Enterprise Database Statistics

Generating a support bundle

  1. Open a web browser and navigate to https://«hostname»:8800 to access the admin console.

    update dashboard 2018.2
  2. Select Support from the navigation menu.

    support dashboard 2017.7
  3. Click the Download Support Bundle button.

    Generation of the Support Bundle may take several minutes to complete. Once the Support Bundle has been generated it will be automatically downloaded.

Build scans

Usage

Creating build scans

Build scans are created from Gradle builds, by using the build scan Gradle plugin. For information on how to use and configure the build scan plugin with your existing Gradle builds, please consult the Build Scan Plugin User Manual.

Viewing build scans

When running a build that publishes build scans, the URL to the build scan for that build is output at the end of the build which looks like this…

Publishing build scan...
https://«hostname»/s/«scan-id»

To view all of the collected build scans, open the Gradle Enterprise application in your browser. This will redirect you to the /scans page where you can search for build scans. Click on a search result to view the build scan.

usage scan list 2018.2

Plugin version compatibility

Compatibility between versions of Gradle Enterprise and the build scan plugin can be found here.

Build cache

Gradle’s build caching dramatically decreases build times for both local development and continuous integration builds. Build caches store outputs from Gradle tasks and serve them to later Gradle builds to reuse, instead of the outputs being built again.

Gradle Enterprise provides a built-in build cache node as part of each installation, and allows optionally connecting one or more remote nodes to use as discrete caches or replicas for reducing network latency.

The build cache administration service is available at /cache-admin of your Gradle Enterprise installation.

Configuration

By default, the built-in cache node provided with Gradle Enterprise is enabled and has no access protection. It also defaults to a cache size of 10 GB and a maximum artifact size of 100 MB. These settings, and access controls, can be configured at any time.

Click the Nodes item in the left menu to access the node listing, then click View built-in node details.

controller built in details 2018.2

Gradle usage

In order to use a build cache, the address of the build cache needs to be configured in your Gradle builds.

The built-in cache node is available via http://«gradle-enterprise-hostname»/cache/ (or with https if configured):

buildCache {
    remote(HttpBuildCache) {
        url = 'https://gradle-enterprise.mycompany.com/cache/'
    }
}

If your Gradle Enterprise installation is using HTTPS with a self-signed or untrusted certificate, connection to the build cache will fail. As of Gradle 4.2, you can allow connections to untrusted servers by adding allowUntrustedServer = true to the configuration:

buildCache {
    remote(HttpBuildCache) {
        url = 'https://gradle-enterprise.mycompany.com/cache/'
        allowUntrustedServer = true
    }
}

Earlier versions of Gradle do not support untrusted HTTPS connections to a build cache.

Remote nodes are available via http://«remote-cache-node-hostname»/cache/ (or with https if configured):

buildCache {
    remote(HttpBuildCache) {
        url = 'https://gradle-cache-node-1.mycompany.com/cache/'
    }
}

For more information about using a build cache from Gradle, please consult the Gradle user manual.

Using multiple caches

When leveraging replication, the build configuration should allowing using the best available cache node. One approach is to set a default cache location, while allowing users to override it for their environment.

This can be done by leveraging system properties:

buildCache {
    remote(HttpBuildCache) {
        url = System.getProperty("buildCacheUrl", "https://cache1/cache/")
    }
}

Users can then specify their best build cache node by adding the following to their ~/.gradle/gradle.properties file:

systemProp.buildCacheUrl=https://cache2/cache/

More automatic schemes are also possible, depending on your environment. For example, if you are able to programmatically determine where the build is running, it may be practical to choose the best cache node automatically within the cache configuration logic.

Remote nodes

Remote build cache nodes are installed separately from Gradle Enterprise. They can be used to separate cache artifacts, distribute load, or improve build performance by having a better network link between the build and the node.

By connecting remote nodes to a Gradle Enterprise instance, you are able to configure them centrally from Gradle Enterprise, and have them replicate entries from other cache nodes.

Installation and operation of remote build cache nodes is documented in the dedicated build cache node manual.

Connecting with Gradle Enterprise

To connect a remote node to your Gradle Enterprise installation, you first need to create a record for the node with Gradle Enterprise.

Visit /cache-admin of your Gradle Enterprise installation, and select Nodes from the left menu. In the Remote nodes > Create new node section, enter the name for your node and click Create new node.

controller after new node added 2018.2

The node will now be listed in the Existing nodes section. 

Each node is assigned a key and a secret. The node needs to be configured with the key and secret.

The secret is only viewable for 5 minutes after node creation. If the node secret is lost, use the regenerate function to issue a new secret which will then be viewable for 5 minutes.
controller secret 2018.2

The node must also be configured with details of the server to connect with, including the assigned key and secret. Please consult the “Gradle Enterprise Registration” section of the build cache node manual for how to do this.

Replication

The bandwidth and latency of the network link between a build and a build cache significantly affects build performance. Replication allows users to use a cache node that they have a better network link to, while reusing artifacts from another cache node that is further away. This is particularly effective for geographically distributed teams.

The replication settings for each node can be configured via the node’s configuration page in Gradle Enterprise. They can not be configured for remote nodes via the remote node’s user interface or configuration file.

A typical arrangement is to have continuous integration builds push to a cache node on a local network, and have other nodes used by developers in different locations, ideally on their local network, use it as their replication source.

replication network

Replication is one-way (i.e. replication sources do not copy artifacts from nodes using them as a source). Furthermore, a node that is acting as a replication source cannot itself use a replication source.

Replication is not supported with remote nodes earlier than 3.0. This setting will not be shown for such nodes.

By default, cache entries are replicated on demand. Nodes will copy a cache entry from their replication source when that particular cache entry is requested for the first time. This avoids copying entries between nodes that will never be used, but forces builds to wait for the transfer on first use.

Preemptive replication enables better build cache performance, at the expense of more network transfer between nodes. When preemptive replication is enabled, nodes will copy cache entries from their replication source as soon as they are added. The downside of this approach is that entries may be copied that are never used. If network bandwidth usage between nodes is not a concern, this is the best configuration.

Only cache entries that are added to the replication source after the node has connected are copied preemptively. Any already existing entries will be copied on demand.

Preemptive replication is only supported for nodes of version 4.0 or later. If the node or its replication source is older than this, replication will be on demand.

Health monitoring

The Health page provides an overview of the operational status of all enabled build cache nodes.

controller health

Each node may have a status of OK, WARN or ERROR. If all nodes are reported as OK, you can be assured that your build cache network is operating well.

WARN indicates that there is a non-critical issue, or that there is a problem that is expected to resolve itself soon. If the issue does not resolve itself, or for immediately critical issues, the ERROR status is used.

A monitoring tool friendly version of this page is available via the Monitoring page link towards the bottom of the page. This endpoint returns the statuses in plain text. If there are any ERROR statuses, the HTTP response status code for this page will be 503. Otherwise, it will be 200.

Uninstalling Gradle Enterprise

To uninstall Gradle Enterprise, you first need to follow the steps to uninstall Replicated, which can be found here.

You can then remove the replicated user that was created on install, by running the command:

sudo userdel -r replicated

This will remove the user, along with their home directory.

Appendix A: Upgrade notes

New scheduled backup configuration options

This release includes changes to automatic scheduled backups. If you have previously configured scheduled backups via the Console Settings section of the admin console you will need to reconfigure scheduled backups via the updated configuration settings described in the Backup and disaster recovery section of this manual. Failure to do so will mean automatic backups will no longer continue to be performed on a scheduled basis.