By default, Gradle Enterprise will store data in a database that runs in a container as part of the Gradle Enterprise installation, and which stores its data in a local file system or persistent volume. This is referred to as the “embedded database”. Starting with Gradle Enterprise 2021.3, it is possible to instead store data in a database that is outside of the Gradle Enterprise application. This is referred to as a “user-managed database”.

This document describes how to switch a Gradle Enterprise instance that has data stored in its embedded database to using a user-managed database, and migrating the data to the new database.

It is strongly recommended to read the entire guide before starting any migration steps.

Data to be migrated

There are a number of different ways to migrate data presented in this guide, all attempting to solve a single problem: migrating a potentially large set of data with minimal service downtime.

Typically, the vast majority of data in a Gradle Enterprise database is Build Scan data, which can be orders of magnitude larger than the rest. For example, some Gradle Enterprise installations have terabytes of Build Scan data, with the rest in the order of megabytes. However, the rest of data in the database is more important for continuous operation. This is data such as app configuration, Build Cache node registration and topology, users, permissions and access keys, which are important to migrate and have available immediately when switching between databases.

Many installations will have a small enough database that they can follow the first and simplest strategy of taking down the service and restoring a database backup to a new database. Other strategies involve either skipping migrating Build Scan data completely, or copying it gradually after switching to using the new database.

Data not migrated

Built-in Build Cache entries are not migrated with any of the strategies in this document. It is assumed that these will be repopulated by simply running the tasks or goals again in the relevant builds, and that this is an acceptable cost when doing this sort of system change.

Contact Gradle Support if this is of concern for your installation.

Prerequisites

Gradle Enterprise version

Support for a user-managed database started with Gradle Enterprise 2021.3. The system should be running at least that version.

Some migration strategies involve setting up a second Gradle Enterprise instance. In these cases, the two instances should be running the same Gradle Enterprise version.

Database scripts

All migration strategies in this guide require running some scripts to set up the new database and copy over some data and configuration settings. Please contact Gradle support prior to starting to be provided with the latest version of these scripts.

User-managed database instance

Gradle Enterprise versions 2021.3 to 2022.1.1 are compatible with PostgreSQL version 12.

Gradle Enterprise versions 2022.2 and later are compatible with PostgreSQL versions 12, 13 and 14.

This guide assumes that you have a compatible PostgreSQL database instance ready to migrate data to. A specific database does not need to have been created (using e.g. CREATE DATABASE) - this will happen as part of the steps below. Please see the relevant section in the appliance administration manual or the Kubernetes administration manual for more details on database setup.

Additional Gradle Enterprise instance

Some of the migration strategies described below involve copying Build Scan data after the initial migration of everything else. This requires setting up a new Gradle Enterprise instance. Please check the feasibility, time and cost of setting up a new instance when deciding on migration strategy.

Gradle Enterprise instance promotion

Some of the migration strategies described below require promoting a new Gradle Enterprise instance to become your main instance that builds connect to. For example, Build Scans will be published to this new instance once the promotion happens. This switch can occur in several ways, depending on your infrastructure setup:

  • If you have a reverse proxy of some sort that sits in front of Gradle Enterprise, this can likely be easily configured to point to a different Gradle Enterprise instance.

  • Many setups use a DNS entry to point to their primary Gradle Enterprise instance that is unrelated to the specific host that Gradle Enterprise is installed on. Promoting a new instance then involves updating the DNS entry.

  • Alternatively, build configuration can be updated to point to a different instance. All build plugins and extensions, Build Cache nodes and Test Distribution agents must be updated to point to the new server. This is often more onerous than updating network infrastructure, but may be a reasonable strategy, depending on how centralized or duplicated your organization’s build configuration is.

If there is no easy promotion path, there are migration strategies that allow use of the existing instance, with certain tradeoffs. Before proceeding with a migration, you should understand the possible promotion strategies for your infrastructure to allow evaluation of the tradeoffs described below.

Service downtime during a backup

Some of the migration strategies below involve taking a backup of the embedded database to allow setting up a second Gradle Enterprise instance. Knowledge of your current backup duration is useful here, to help in evaluating likely downtime during the migration.

Build scan copying

Some of the migration strategies below involve copying Build Scans into the new database. This requires a machine on which to run the copy tool. This may be a machine with Gradle Enterprise installed, or may need to be a different machine, depending on your network settings and Gradle Enterprise instances. See the appendix for more details.

Disk space cleanup

In all strategies below, the data directory or persistent volume on which the embedded database is stored is left in place until a final cleanup step. This means that if there is any unexpected issue during the migration, the original data is still where it was so it should be possible to revert any changes and resume using the embedded database. Once all other steps have been completed it should be safe to clean this up as described below.

Migration strategies

Different strategies are presented here, each with different trade-offs. Please read through them and choose the best for your build and network infrastructure.

Recommended options:

Please contact Gradle support for assistance in picking the correct migration strategy for your installation.

Strategy 1: Migrate all data up-front, offline

This approach migrates all data in one go, while the application is unavailable.

Tradeoffs

Pros:

  • All data copied in a single step

Cons:

  • Requires downtime while data is dumped and restored. This will be significant for installations with a lot of data.

Steps

  1. Consider doing a test run, to measure the likely downtime and ensure that it is acceptable for your organization.

  2. Perform initial database setup.

  3. Stop the enterprise app while leaving the database running. This ensures that no data is lost when switching to the new database. Your Gradle Enterprise instance will be unavailable at this point.

  4. Run the data migration script, making sure to pass the --include-build-scans parameter. This copies all data to the new database.

  5. Configure your Gradle Enterprise instance to point to your new database.

    • For appliance installations this is done on the settings screen. You will be prompted to restart the application - do so.

    • For Kubernetes installations this is done while running the install script. Once the installer script is finished, Gradle Enterprise Kubernetes resources will be restarted.

  6. Wait for Gradle Enterprise to complete restarting.

  7. Smoke test your Gradle Enterprise instance to ensure that it’s operational.

  8. Test that your normal builds are functioning, including Build Scan publishing, Build Cache usage and Test Distribution, depending on which features are used in your builds.

  9. Once you are satisfied that the instance attached to the new database is fully operational and has the correct data, it is safe to clean up the old data.

Strategy 2: Migrate all non-Build-Scan data

This approach migrates all data except for Build Scan data, which is not retained.

Tradeoffs

Pros:

  • Minimal downtime

  • No need to create a second instance

  • No need to promote an instance

Cons:

  • Build scan data is not retained

Steps

  1. Perform initial database setup.

  2. Stop the enterprise app while leaving the database running. This ensures that no data is lost when switching to the new database. Your Gradle Enterprise instance will be unavailable at this point.

  3. Run the data migration script. This copies all non Build Scan data to the new database.

  4. Configure your Gradle Enterprise instance to point to your new database.

    • For appliance installations this is done on the settings screen. You will be prompted to restart the application - do so.

    • For Kubernetes installations this is done while running the install script. Once the installer script is finished, Gradle Enterprise Kubernetes resources will be restarted.

  5. Wait for Gradle Enterprise to complete restarting.

  6. Smoke test your Gradle Enterprise instance to ensure that it’s operational.

  7. Test that your normal builds are functioning, including Build Scan publishing, Build Cache usage and Test Distribution, depending on which features are used in your builds.

  8. Once you are satisfied that the instance attached to the new database is fully operational and has the correct data, it is safe to clean up the old data.

Strategy 3: Restore backup to a secondary Gradle Enterprise instance, connect primary to new database

This approach takes a backup of the data, starts a new, temporary instance of Gradle Enterprise with that data, and configures the existing instance to point to the user-managed database. All new data will be on the primary instance, and historical data can be viewed on the secondary instance. After a period of time, the secondary instance can be decommissioned.

Tradeoffs

Pros

  • All data is available immediately

  • No need to promote an instance

Cons:

  • Historical data is only available on the second instance

  • Resources are required for the second instance as long as the historical data on it is needed

  • Service will be down while the database backup is taken

  • A potentially large backup must be copied to a new instance

Steps

  1. Perform initial database setup.

  2. Create and install a new Gradle Enterprise instance. This instance will be a secondary Gradle Enterprise instance that provides access to historical data. It will need enough storage to hold both a copy of the database and a backup of it. Configure the instance to connect to its embedded database.

  3. On the primary instance, stop the enterprise app while leaving the database running. This ensures that no data is lost when switching to the new database. Your Gradle Enterprise instance will be unavailable at this point.

  4. Run the data migration script.

  5. Take a backup of the database on your primary Gradle Enterprise instance. See the appliance administration manual or the Kubernetes administration manual as appropriate.

  6. Configure the primary Gradle Enterprise instance to point to the new database.

    • For appliance installations this is done on the settings screen. You will be prompted to restart the application - do so.

    • For Kubernetes installations this is done while running the install script. Once the installer script is finished, Gradle Enterprise Kubernetes resources will be restarted.

  7. Smoke test the primary instance to ensure that it’s operational.

  8. Test that your normal builds are functioning, including Build Scan publishing, Build Cache usage and Test Distribution, depending on which features are used in your builds.

  9. At this point, your primary instance is now connected to your database and is storing its data there. New Build Scan data will be published to the database, but Build Scan history will not be present.

  10. Copy the backup to your secondary Gradle Enterprise instance.

  11. Stop Gradle Enterprise on the secondary instance.

  12. Restore the backup on your secondary instance. See the appliance administration manual or the Kubernetes administration manual as appropriate.

  13. Start the secondary instance up again.

  14. At this point, you can access historical scans and trends data up to the backup point on the secondary instance.

  15. Keep the secondary instance running as long as the historical data is useful. It can be decommissioned on your preferred schedule.

Strategy 4: Set up and promote new Gradle Enterprise instance, copy Build Scan data to it

This approach migrates all non Build Scan data and configuration to a new user-managed database, starts a new instance of Gradle Enterprise connected to that database, promotes the new instance, then copies scans data to the new instance.

Tradeoffs

Pros

  • All data is copied eventually

  • Second volume of storage capable of holding the database is not required

  • Short downtime

Cons:

  • Historical data is only available on the original instance initially

  • Resources for a second Gradle Enterprise instance are required while Build Scan data is copied

  • Requires ability to promote a new instance

Steps

  1. Perform initial database setup.

  2. Create and install a new Gradle Enterprise instance. This instance will be the new Gradle Enterprise instance at the end of this procedure and so it needs to be provisioned (CPU, memory) as well as the current instance, with the exception that it does not need a large disk to handle Build Scan data in the database. At this stage, install it configured to use the embedded database.

  3. Ensure that any pre-promotion steps have been completed.

  4. Ensure that you have run through the Build Scan copy pre-verification steps.

  5. On the original instance, stop the enterprise app while leaving the database running. This ensures that no data is lost when switching to the new database. Your Gradle Enterprise instance will be unavailable at this point.

  6. Run the data migration script.

  7. Configure the new Gradle Enterprise instance to point to the new database.

    • For appliance installations this is done on the settings screen. You will be prompted to restart the application - do so.

    • For Kubernetes installations this is done while running the install script. Once the installer script is finished, Gradle Enterprise Kubernetes resources will be restarted.

  8. Smoke test the new instance to ensure that it’s operational.

  9. Promote the new Gradle Enterprise instance, using whatever promotion strategy is suitable for your environment, as discussed above.

  10. Test that your normal builds are functioning using the new instance, including Build Scan publishing, Build Cache usage and Test Distribution, depending on which features are used in your builds.

  11. At this point, your new instance is now the main Gradle Enterprise instance for you organization. New Build Scan data will be published to it, but Build Scan history will not be present. If your original instance’s web interface is still available after the new instance is promoted, historical Build Scan data up to the switchover point will be available on that URL.

  12. Start the Build Scans copy tool. This tool will copy Build Scans from your original instance to the new one, starting with the most recent first, to restore trends data for the most recent Build Scans first.

  13. At any point, if you decide that enough historical data has been copied to the new instance, you can terminate the copier tool.

  14. Once you are satisfied that the new instance is fully operational and has the correct data, the original instance can be decommissioned on your preferred schedule.

Strategy 5: Copy Build Scan data from second, temporary instance

This approach takes a backup of the data, starts a new, temporary instance of Gradle Enterprise with that data, configures the existing instance to point to the user-managed database and then copies Build Scan data from the temporary instance.

Tradeoffs

Pros

  • All data is copied eventually

  • No need to promote a new instance

Cons:

  • Historical data is only available on the second instance initially

  • Resources for a second Gradle Enterprise instance are required while Build Scan data is copied

  • Service will be down while the database backup is taken

  • Potentially large backup must be copied to new instance

Steps

  1. Perform initial database setup.

  2. Create and install a new Gradle Enterprise instance. This instance will be a temporary Gradle Enterprise instance that is used by the copy tool to copy Build Scan data into the new database. It will need enough storage to hold both a copy of the database and a backup of it. Configure the instance to connect to its embedded database.

  3. Ensure that you have run through the Build Scan copy pre-verification steps.

  4. On your original instance, stop the enterprise app while leaving the database running. This ensures that no data is lost when switching to the new database. Your Gradle Enterprise instance will be unavailable at this point.

  5. Run the data migration script.

  6. Take a backup of the database on your original Gradle Enterprise instance. See the appliance administration manual or the Kubernetes administration manual as appropriate.

  7. Configure the original Gradle Enterprise instance to point to the new database.

    • For appliance installations this is done on the settings screen. You will be prompted to restart the application - do so.

    • For Kubernetes installations this is done while running the install script. Once the installer script is finished, Gradle Enterprise Kubernetes resources will be restarted.

  8. Smoke test the original instance to ensure that it’s operational.

  9. Test that your normal builds are functioning, including Build Scan publishing, Build Cache usage and Test Distribution, depending on which features are used in your builds.

  10. At this point, your original instance is now connected to your database and is storing its data there. New Build Scan data will be published to it, but Build Scan history will not be present.

  11. Copy the backup to your new Gradle Enterprise instance.

  12. Stop Gradle Enterprise on the new instance.

  13. Restore the backup on your new instance. See the appliance administration manual or the Kubernetes administration manual as appropriate.

  14. Start the new instance up again.

  15. At this point, you can access historical Build Scans and trends data up to the backup point on the new instance if necessary.

  16. Start the Build Scans copy tool. This tool will copy Build Scan data from your new, temporary instance back to the original instance, which will store them into the new database, starting with the most recent first, to restore trends data for the most recent Build Scans first.

  17. At any point, if you decide that enough historical data has been copied to the new database, you can terminate the copier tool.

  18. Once you are satisfied that the new database is fully operational and has the correct data, the temporary Gradle Enterprise instance can be decommissioned at your preferred schedule.

  19. It is also safe to clean up the old data on the original instance at this point.

Appendix A: Testing a full migration to determine likely downtime

This method tests how long the system would likely be unavailable during a migration by performing one as a test run.

  1. Perform initial database setup. If you are not providing superuser credentials for the database to Gradle Enterprise, set the passwords on the new accounts.

  2. Run the data migration script, ensuring that Build Scan data is copied, logging the starting and ending time. For example:

    date ; ./migrate-from-embedded.sh --include-build-scans [other args] ; date
    The time utility can also be used to measure duration, if it’s available in your environment.
  3. At any point, if the process has taken longer than would be acceptable, it may be terminated.

When the script completes, the difference between the initial and final logged timestamps is an estimate of how long the system would be unavailable if data is migrated in this fashion. This can then be used to determine if a full up-front migration is a viable strategy for your organization.

After completing the test, the user-managed database should be dropped and recreated to have a clean database for the final migration.

Appendix B: Initial database setup

Normally, when connecting to a user-managed database, Gradle Enterprise is configured with database superuser credentials. These are used to set up database schemas and less privileged accounts that it then uses to access the database day-to-day.

It is possible to configure Gradle Enterprise without providing superuser credentials. In that configuration, once per major release, a database setup script must be run manually. This sets up the schemas and other accounts, and Gradle Enterprise is then configured with credentials for the other accounts.

When performing any of the migration strategies in this document, this script must also be run.

Steps

  1. Contact Gradle support to receive the database script bundle.

  2. Create your database using CREATE DATABASE or an equivalent in your database provider interface.

  3. Run the setup script on a host that can connect to your database:

    PGPASSWORD="xxx-postgres-user-password" ./setup.sh --host=db.myhost.com

    Run the script without arguments to see full options (e.g. different username, non-default port etc).
    This will create two accounts: ge_app and ge_migrator.

  4. If your Gradle Enterprise installation will not be configured with superuser credentials, set the passwords for the two new accounts, using psql or an equivalent query tool:

    psql -h db.myhost.com -U postgres ALTER USER ge_app PASSWORD 'the_app_password'
    psql -h db.myhost.com -U postgres ALTER USER ge_migrator PASSWORD 'the_migrator_password'

    These passwords will be required when configuring Gradle Enterprise to connect to the database.

Appendix C: Stopping the Gradle Enterprise application while leaving its embedded database running

This is done to ensure that data such as user access keys and manually defined roles, build cache node registrations and topology, and Test Distribution agent pools do not have changes which are lost when switching databases.

Kubernetes installations

  • Run the following commands:

    kubectl --namespace=«your-namespace» scale --replicas=0 statefulset/gradle-enterprise-app
    kubectl --namespace=«your-namespace» scale --replicas=0 statefulset/gradle-keycloak

    Or, for an OpenShift install:

    oc scale --replicas=0 statefulset/gradle-enterprise-app
    oc scale --replicas=0 statefulset/gradle-keycloak

Appliance installations

  • Run the following command:

    docker stop gradle-enterprise-app
    docker stop gradle-keycloak

Appendix D: Running the database migration script

Steps

  1. Contact Gradle support to receive the database script bundle.

  2. Run the migration script:

    DESTINATION_PASSWORD="xxx" ./migrate-from-embedded.sh --installation-type=appliance --destination-host=my-host.db.com

    Run the script without arguments to see full options (e.g. different username, non-default port etc).

  3. Verify that the script terminates with a Database migration complete message

If any errors occur, it is recommended to drop and recreate your database, then restart from the first steps of your chosen strategy.

Appendix E: Smoke testing a Gradle Enterprise instance

This involves running a normal build, pointed at your Gradle Enterprise instance, and verifying that:

  • A Build Scan is published and appears as expected when its reported URL is visited.

  • The Build Cache was used if expected.

  • Test Distribution was used if expected.

There are a few ways to do this:

Appendix F: Pre-promotion steps

The aim here is to ensure that builds can be converted to use a new instance as fast as possible. The specific steps will vary, depending on your infrastructure and promotion strategy. Some suggested steps for known setups:

  • If your promotion strategy involves updating DNS records, you should ensure that these have a small time-to-live (TTL) ahead of time. For example, if your DNS entries usually have a TTL of 24h, you should lower this to a short TTL a day ahead of the migration, to allow time for the entries with the longer TTL to expire from DNS caches in your infrastructure.

  • If your promotion strategy requires other staff in your organization to perform changes, e.g. to update DNS records or change reverse proxy or other network settings, it is recommended to schedule a time to perform the critical parts of the migration to ensure that they are available to perform a switchover at the appropriate moment.

  • If your promotion strategy involves updating build configuration, it is recommended to have a checklist of builds that need to be updated. If your code infrastructure supports it, having pull requests or equivalent for each case ready to go can reduce the effective downtime that builds will experience.

Appendix G: Build Scan copy pre-verification steps

The Build Scan copy tool operates by copying Build Scans from one Gradle Enterprise server to another. To do this effectively, it needs network access to both servers, and access keys if necessary.

Steps:

  • Choose a host to run the copy tool on that will be able to access the normal URL of each server involved. This may be the host of one of the Gradle Enterprise instances - if both would work, it is recommended to use the server that the tool is copying Build Scans from, so as to not increase load on the production server.

  • Verify that both instances are accessible from the host that you will run the copy tool on. This can be done in various ways, but typically a tool like curl is available to do it:

    curl https://source-gradle-enterprise-server.company.com/info/version
    curl https://destination-gradle-enterprise-server.company.com/info/version

    If you cannot connect to either server, either discuss your network setup with an appropriate administrator ot try another host.

  • The copy tool requires access keys if the equivalent operations would require them. This means that it needs an access key for a user with Build Scan publishing permissions if anonymous access to publish Build Scans is disabled on the destination server, see the administration manual. It also will need an access key with “Build data export” permissions if this permission is not granted to anonymous users on the source server, see the Export API manual.

  • The tool can be run as a Java executable JAR file or as a docker container.

    • If running as a JAR, ensure that you have a JDK 11 compatible Java runtime installed, download the latest version from here and verify that it works by running it using:

      java -jar gradle-enterprise-scans-copy-«version».jar
    • If running as a docker container, verify that it can be pulled and run using:

      docker run --rm gradle/gradle-enterprise-scans-copy-cli:latest

Appendix H: Running the Build Scans copy tool

Assuming that you have run through the pre-copy verification steps, running the copier is straight-forward.

Please ensure that your system has at least 2GB of memory available.

Access keys

If your destination servers require access keys, export:

  • SOURCE_ACCESS_KEY for an access key with export permissions from the source server

  • DESTINATION_ACCESS_KEY for an access key with Build Scan publish permissions from the destination server

Docker

Run as a docker container, optionally providing the access key environmental variables if appropriate:

docker run \
  --detach \
  --name=gradle-enterprise-scans-copy-cli \
  -e SOURCE_ACCESS_KEY \
  -e DESTINATION_ACCESS_KEY \
  gradle/gradle-enterprise-scans-copy-cli:latest copy \
  --sourceUrl=https://source-gradle-enterprise-server.company.com/ \
  --destinationUrl=https://destination-gradle-enterprise-server.company.com/

To follow progress, check the output in the docker logs:

docker logs --follow gradle-enterprise-scans-copy-cli

The Build Scans copy tool will write a file containing IDs of Build Scans that it was unable to copy to a file in the current directory.

This file can be retrieved from the container from its /home directory. The default filename is failures.txt, though this can be changed via a command line argument.

docker cp gradle-enterprise-scans-copy-cli:/home/failures.txt ./failures.txt

To instead have this file written to your local filesystem automatically, mount a local directory to the /home directory inside the container. For example:

mkdir ~/copy-failures

docker run \
  --detach \
  -v ~/copy-failures:/home \
  --name=gradle-enterprise-scans-copy-cli \
  gradle/gradle-enterprise-scans-copy-cli:latest copy \
  --sourceUrl=https://source-gradle-enterprise-server.company.com/ \
  --destinationUrl=https://destination-gradle-enterprise-server.company.com/

Executable JAR

The Build Scans copy tool has been tested against JDK 11 versions.

Run it with the following command:

java -Xms1024m -Xmx1024m -XX:MaxDirectMemorySize=512m \
  -jar gradle-enterprise-scans-copy-«version».jar \
  copy \
  --sourceUrl=https://source-gradle-enterprise-server.company.com/ \
  --destinationUrl=https://destination-gradle-enterprise-server.company.com/

As the tool is expected to run for a significant amount of time, it is recommended to detach it from the terminal and examine progress via logs:

nohup \
  java -Xms1024m -Xmx1024m -XX:MaxDirectMemorySize=512m \
  -jar gradle-enterprise-scans-copy-«version».jar \
  copy \
  --sourceUrl=https://source-gradle-enterprise-server.company.com/ \
  --destinationUrl=https://destination-gradle-enterprise-server.company.com/
  >> gradle-enterprise-scans-copy.log 2>&1 \
  & disown

tail -f gradle-enterprise-scans-copy.log

Additional arguments

There are a few command line arguments that the tool accepts - run it with java -jar gradle-enterprise-scans-copy-«version».jar copy --help to see them all.

The most commonly used is --copyScanDataSince, which allows specifying a date beyond which only Build Scan ids should be copied, not the data itself. This effectively simulates the normal time-based retention window of Gradle Enterprise’s disk space management. Scans copied whose date was after the given date will be copied in full; older Build Scans will be copied such that if they are visited in the Gradle Enterprise UI, the user will be informed that the Build Scan has been deleted.

Restarting the copy tool

The copy tool may need to be restarted if interrupted.

Typically the process is:

  • Examine the logs from the last run and identify the last succesfully copied Build Scan

  • If running as a docker container, remove the old container using docker stop and docker rm

  • Rerun with an additional argument, --startWithBuildId=«build-scan-id» - the tool will resume copying Build Scans, starting with the next oldest after the one specified and working backwards chonologically from there.

Note that it’s safe to rerun the copy tool overlapping the range of Build Scans to copy with a previous run. Build Scans that have been previously copied will be detected and reported, and the copy tool will continue to copy other Build Scans.

Appendix I: Cleaning up the data directory or persistent volume

Once you are happy that the new database has all the data that you wanted migrated and the system is operational, you may wish to remove the old data, and potentially remove attached storage.

For appliance installations, the data is typically in a data/postgresql subdirectory of the installation directory. For example, if using the default /opt/gradle installation directory, the database directory is /opt/gradle/data/postgresql. This directory can be safely deleted once the new setup is fully operational.

For Kubernetes installations, the associated PersistentVolumeClaim is called gradle-database-volume and can be deleted using the following commands:

kubectl --namespace=«your-namespace» delete --ignore-not-found=true pvc/gradle-database-volume

Or, for an OpenShift install:

oc delete --ignore-not-found=true pvc/gradle-database-volume

Depending on your reclaim policy, you may need to perform other manual steps to reclaim the space used. See the Kubernetes documentation for more details.

Appendix J: Gradle Enterprise Scans Copy CLI JAR downloads