2025.1 Develocity Upgrade Guide | Develocity Documentation

1. Overview

Upgrading to a new version of Develocity provides your organization with new features, improved functionality, and security updates.

This page provides the steps to upgrade Develocity from version 2024.3 to version 2025.1. If you are upgrading from a version older than 2024.3, please refer to the 2024.3 Upgrade Guide and address all breaking changes before proceeding with this guide.

The 2025.1 release introduces a new monitoring solution. If you use user-managed Object Storage, you must update your configuration.

Starting with the 2025.1 release, the values.yaml file is validated by Helm. Any invalid keys or values in your configuration will now trigger schema validation errors, ensuring that configurations remain correct.

Further details can be found in the changes appendix.

2. Compatibility table

The versions below were confirmed to work with Develocity 2025.1.

Supported software versions
Software	Minimum version	Latest version
Kubernetes	1.30	1.32
Helm	3.15	3.17
PostgreSQL	14	17

Check the compatibility matrix for a full overview of the version compatibility of Develocity with related components.

3. User-managed database

For major version upgrades (for example, 2024.3 to 2025.1), if data is stored in a user-managed database and superuser credentials are not supplied, the database setup script must be run before the upgrade.

The corresponding script for Develocity 2025.1 can be downloaded via the following link

gradle-enterprise-database-setup-zip-2025.1.zip (SHA-256 checksum)

Depending on the size of your database, it may take from a few minutes to up to hours.

It’s strongly recommend to make a database backup before upgrading.

Upgrading Develocity irreversibly changes the database schema.
You will need to restore the database from a backup if you need to roll back the upgrade.

4. Standalone

4.1. Online

4.1.1. Upgrade K3s

Running the following command will:

Download the latest k3s binary supported by Develocity 2025.1.
Restart the k3s service.

$ curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=v1.32 sh -

For more information, see the official K3s upgrade documentation.

At this point, you still run the old version of Develocity.
Please confirm it works as expected before proceeding with the upgrade.

Accessing the application and verifying it receives new Build Scan data is the easiest method.

4.1.2. Upgrade Helm

Running the following commands will:

Download the Helm installation script.
Set the permissions of the script. Only the owner has read, write, and execute permissions.
Install the Helm version specified with the -v flag.

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3

$ chmod 700 get_helm.sh

$ ./get_helm.sh -v v3.17.2

For more information, see the official Helm installation documentation.

Verify that helm is installed and working:

$ helm version

4.1.3. Upgrade Develocity

Update repository

First, run the helm repo update gradle command to update locally available charts:

$ helm repo update gradle

Adjust values.yaml configuration

Adjust your values.yaml configuration file. You can find a detailed list of required changes in the appendix.

You can discover your current configuration by running the following command:

$ helm get values \
    --namespace develocity \(1)
    ge-standalone \(2)
    > values.yaml (3)

1	The namespace used to install Develocity.
2	Release name.
3	Output file.

Decide on the upgrade command

You may need to run different upgrade commands depending on your configuration changes.
You can find recommendations in the appendix.

Use `dry-run` to verify the upgrade

Before upgrading, you can use the --dry-run flag to verify the upgrade process.
This will show you the changes that would be made without actually applying them.

For example (if no changes were required):

$ helm upgrade \
    --namespace develocity \
    --reuse-values \
    --version 2025.1.1 \
    ge-standalone \
    gradle/gradle-enterprise-standalone \
    --dry-run

The actual command may differ depending on the outcome from the previous step.

If the --dry-run command completes successfully, you can proceed with the upgrade.
Otherwise, review the output and make any necessary changes to your configuration.

--dry-run validates syntax, verifies the chart structure, validates your configuration with schema, and checks the generated Kubernetes manifests for errors. However, it won’t detect issues like typos in optional fields or guarantee the application configuration will function correctly.

Execute the upgrade

Remove --dry-run from the command above and execute the upgrade.

For example (if no changes were required):

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

4.2. Airgap

Upgrading an airgap instance of Develocity requires downloading the latest version of charts, transferring them to the host machine, and installing them. Downloading an update for Develocity requires your license file.

If you use helm template (or --reset-values), you must specify all installation options again, including files. You must transfer these files to the machine used to access the cluster.

4.2.1. Download required files

Download K3s

Running the following commands will:

Download the K3s binary.
Download the K3s airgap image.
Download the K3s installation script.

Download the K3s binary:

$ curl -LO https://github.com/k3s-io/k3s/releases/download/v1.32.2+k3s1/k3s

Download the K3s airgap image:

$ curl -LO \
    https://github.com/k3s-io/k3s/releases/download/v1.32.2%2Bk3s1/k3s-airgap-images-amd64.tar.gz

Download the K3s installation script:

$ curl -L -o install_k3s.sh https://get.k3s.io

If you are running Red Hat Enterprise Linux with SELinux enabled, download the K3s policy package:

SELinux policy package download

Lookup the latest version of the K3s SELinux Policy package:

$ K3S_SELINUX_DOWNLOAD_URL=$(curl -s https://api.github.com/repos/k3s-io/k3s-selinux/releases/latest | jq -r '.assets[] | select( .name | endswith("el8.noarch.rpm") ) | .browser_download_url') && echo $K3S_SELINUX_DOWNLOAD_URL

You can view the versions available and find the download links on the K3s SELinux releases page.

Then download it:

$ curl -L -o k3s-selinux.el8.noarch.rpm $K3S_SELINUX_DOWNLOAD_URL

Download Helm

Download the Helm binary:

$ curl -L -o helm-linux-amd64.tar.gz https://get.helm.sh/helm-v3.17.2-linux-amd64.tar.gz

Download airgap bundle

Save your Develocity license to the transfer directory as develocity.license.

Download and verify the airgap bundle:

$ curl -LOJd @develocity.license \
    https://registry.gradle.com/airgap/gradle-enterprise-standalone-2025.1.1-bundle.tar.gz

$ curl -LOJd @develocity.license \
    https://registry.gradle.com/airgap/gradle-enterprise-standalone-2025.1.1-bundle.tar.gz.sha256

$ sha256sum -c gradle-enterprise-standalone-2025.1.1-bundle.tar.gz.sha256

If the 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.2.2. Transfer files

Check that the transfer directory has 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-standalone-2025.1.1-bundle.tar.gz

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

4.2.3. Import the new container images

The new Develocity images must be imported into K3s’s embedded container registry.

Run the following commands to:

Unpack the airgap bundle.
Imports Develocity’s images into K3s.

$ tar zxvf gradle-enterprise-standalone-2025.1.1-bundle.tar.gz

$ sudo k3s ctr images import gradle-enterprise-standalone-2025.1.1-images.tar

4.2.4. Upgrade K3s

Follow these instructions on the host where you install Develocity with your transferred files in the current directory.

If you are running Red Hat Enterprise Linux with SELinux enabled, first install the necessary policy packages:

SELinux Policy installation

Install the `container-selinux` package

Install the K3s SELinux Policy package you downloaded:

$ sudo yum install -y k3s-selinux.el9.noarch.rpm

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"

Verify that you can interact with the K3s cluster:

$ kubectl get namespace

Output

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

At this point, you still run the old version of Develocity.
Please confirm it works as expected before proceeding with the upgrade.

Accessing the application and verifying it receives new Build Scan data is the easiest method.

4.2.5. Upgrade Helm

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

Run the following commands to unpack and 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

4.2.6. Upgrade Develocity

Adjust values.yaml configuration

Adjust your values.yaml configuration file. You can find a detailed list of required changes in the appendix.

You can discover your current configuration by running the following command:

$ helm get values \
    --namespace develocity \(1)
    ge-standalone \(2)
    > values.yaml (3)

1	The namespace used to install Develocity.
2	Release name.
3	Output file.

Decide on the upgrade command

You may need to run different upgrade commands depending on your configuration changes.
You can find recommendations in the appendix.

Use `dry-run` to verify the upgrade

Before upgrading, you can use the --dry-run flag to verify the upgrade process.
This will show you the changes that would be made without actually applying them.

For example (if no changes were required):

$ helm upgrade \
    --namespace develocity \
    --reuse-values \
    ge-standalone \
    gradle-enterprise-standalone-2025.1.1.tgz \
    --dry-run

The actual command may differ depending on the outcome from the previous step.

If the --dry-run command completes successfully, you can proceed with the upgrade.
Otherwise, review the output and make any necessary changes to your configuration.

Execute the upgrade

Remove --dry-run from the command above and execute the upgrade.

For example (if no changes were required):

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

5. Kubernetes

Kubernetes installation type is for advanced users. This section assumes that you have a base knowledge of Kubernetes.

5.1. Upgrading with multiple replicas

If you have configured more than one replica, you must scale the replicas down to one before upgrading to avoid having mixed versions running simultaneously.

Before applying the upgrade, run the following command to scale the application down to one replica.

5.1.1. Scale down the application to one replica

$ helm upgrade \
    --namespace develocity \
    --reuse-values \
    --set=global.scaling.replicas=1 \
    --version «PREVIOUSLY_DEPLOYED_VERSION» \(1)
    ge
    gradle/2024.3.4 (2)

1	`«PREVIOUSLY_DEPLOYED_VERSION»` is the running version of Develocity (e.g. 2024.3.4), not the version you are upgrading to.
2	Replace `gradle/gradle-enterprise` with `gradle-enterprise-2024.3.4.tgz` for airgap installations.

5.1.2. Upgrade Develocity

Use online or airgap instructions below to upgrade Develocity.

5.1.3. Scale up the application to N replicas

Before you scale up the application, ensure the upgrade went well and the application is working.

$ helm upgrade \
    --namespace develocity \
    --reuse-values \
    --set=global.scaling.replicas=N \(1)
    --version «NEWLY_DEPLOYED_VERSION» \(2)
    ge
    gradle/gradle-enterprise (3)

1	`N` is the number of replicas you want to scale up to.
2	`«NEWLY_DEPLOYED_VERSION»` is the version of Develocity you just upgraded to (e.g. 2025.1.1).
3	Replace `gradle/gradle-enterprise` with `gradle-enterprise-2025.1.1.tgz` for airgap installations.

5.2. Online

5.2.1. Upgrade Helm

Running the following commands will:

Download the Helm installation script.
Set the permissions of the script. Only the owner has read, write, and execute permissions.
Install the Helm version specified with the -v flag.

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3

$ chmod 700 get_helm.sh

$ ./get_helm.sh -v v3.17.2

For more information, see the official Helm installation documentation.

Verify that helm is installed and working:

$ helm version

5.2.2. Upgrade Develocity

Update repository

First, run the helm repo update gradle command to update locally available charts:

$ helm repo update gradle

Adjust values.yaml configuration

Adjust your values.yaml configuration file. You can find a detailed list of required changes in the appendix.

You can discover your current configuration by running the following command:

$ helm get values \
    --namespace develocity \(1)
    ge \(2)
    > values.yaml (3)

1	The namespace used to install Develocity.
2	Release name.
3	Output file.

Decide on the upgrade command

You may need to run different upgrade commands depending on your configuration changes.
You can find recommendations in the appendix.

Use `dry-run` to verify the upgrade

Before upgrading, you can use the --dry-run flag to verify the upgrade process.
This will show you the changes that would be made without actually applying them.

For example (if no changes were required):

$ helm upgrade \
    --namespace develocity \
    --reuse-values \
    --version 2025.1.1 \
    ge \
    gradle/gradle-enterprise \
    --dry-run

The actual command may differ depending on the outcome from the previous step.

If the --dry-run command completes successfully, you can proceed with the upgrade.
Otherwise, review the output and make any necessary changes to your configuration.

Execute the upgrade

Remove --dry-run from the command above and execute the upgrade.

For example (if no changes were required):

$ helm upgrade \
    --namespace develocity \
    --reuse-values \
    --version 2025.1.1 \
    ge \
    gradle/gradle-enterprise

5.3. Airgap

If you use helm template (or --reset-values), you must specify all installation options again, including files. You must transfer these files to the machine used to access the cluster.

5.3.1. Download required files

Download Helm

Download the Helm binary:

$ curl -L -o helm-linux-amd64.tar.gz https://get.helm.sh/helm-v3.17.2-linux-amd64.tar.gz

Download airgap bundle

Save your Develocity license to the transfer directory as develocity.license.

Download and verify the airgap bundle:

$ curl -LOJd @develocity.license \
    https://registry.gradle.com/airgap/gradle-enterprise-2025.1.1-bundle.tar.gz

$ curl -LOJd @develocity.license \
    https://registry.gradle.com/airgap/gradle-enterprise-2025.1.1-bundle.tar.gz.sha256

$ sha256sum -c gradle-enterprise-2025.1.1-bundle.tar.gz.sha256

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.

5.3.2. Transfer files

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

helm-linux-amd64.tar.gz
gradle-enterprise-2025.1.1-bundle.tar.gz

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

5.3.3. Upload images

Follow these instructions on the host with connectivity to the internal container registry with your transferred files present in the current directory.

You must be logged in to the registry before running these commands.

Run the following commands to unpack the bundle and upload the images to the internal container registry:

$ tar zxvf gradle-enterprise-2025.1.1-bundle.tar.gz

$ ./upload-images.sh --registry=registry.example.com/gradle-enterprise

5.3.4. Upgrade Helm

Follow these instructions on the host with connectivity to the Kubernetes cluster with your transferred files present in the current directory.

Run the following commands to unpack and 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

5.3.5. Upgrade Develocity

Adjust values.yaml configuration

Adjust your values.yaml configuration file. You can find a detailed list of required changes in the appendix.

You can discover your current configuration by running the following command:

$ helm get values \
    --namespace develocity \(1)
    ge \(2)
    > values.yaml (3)

1	The namespace used to install Develocity.
2	Release name.
3	Output file.

Decide on the upgrade command

You may need to run different upgrade commands depending on your configuration changes.
You can find recommendations in the appendix.

Use `dry-run` to verify the upgrade

Before upgrading, you can use the --dry-run flag to verify the upgrade process.
This will show you the changes that would be made without actually applying them.

For example (if no changes were required):

$ helm upgrade \
    --namespace develocity \
    --reuse-values \
    ge \
    gradle-enterprise-2025.1.1.tgz \
    --dry-run

The actual command may differ depending on the outcome from the previous step.

If the --dry-run command completes successfully, you can proceed with the upgrade.
Otherwise, review the output and make any necessary changes to your configuration.

Execute the upgrade

Remove --dry-run from the command above and execute the upgrade.

For example (if no changes were required):

$ helm upgrade \
    --namespace develocity \
    --reuse-values \
    ge \
    gradle-enterprise-2025.1.1.tgz

6. Appendix

Appendix A: Changes

The new monitoring system introduced in 2025.1 requires some extra configuration to be fully operational. Follow one of the actions below to update your configuration.

Develocity 2025.1 introduces the ability for access keys to expire automatically based on age.
By default, access key expiration is enabled with a maximum lifespan of 365 days.
Follow the instructions below if you want to disable this feature.

6.1. `monitoring` configuration when using user-managed Object Storage

The new gradle-monitoring component stores its data in an Object Storage, and a new section of the values.yaml was introduced for it. This new monitoring section is mandatory and the installation will fail if the value is not provided.

Develocity chart configuration offers the ability to use different buckets for "application data" (build scans, build cache) and "monitoring data" (metrics). Storing data in different buckets allows you to apply various strategies, such as access control, replication, soft-delete, backup, and more.

However, you can also use the same bucket for both application and monitoring data; this is an operation’s decision based on your practices.

6.1.1. AWS S3 Object Storage

before.yaml

objectStorage:
  type: s3
  s3:
    bucket: develocity-application-data
    region: aws-region
    credentials:
      type: …

after.yaml

objectStorage:
  type: s3
  s3:
    bucket: develocity-application-data
    region: aws-region
    credentials:
      type: …
    monitoring:
      bucket: develocity-monitoring-data
      region: aws-region
      credentials:
        type: …

For more details about the available configuration options, we recommend you to read the Kubernetes Helm Chart Configuration Guide or the Standalone Helm Chart Configuration Guide based on your installation type.

6.1.2. Google Cloud Storage

before.yaml

objectStorage:
  type: googleCloudStorage
  googleCloudStorage:
    bucket: develocity-application-data
    credentials:
      type: …

after.yaml

objectStorage:
  type: googleCloudStorage
  googleCloudStorage:
    bucket: develocity-application-data
    credentials:
      type: …
    monitoring:
      bucket: develocity-monitoring-data
      credentials:
        type: …

6.1.3. Azure Blob Storage

before.yaml

objectStorage:
  type: azureBlobStorage
  azureBlobStorage:
    container: develocity-application-data
    credentials:
      type: …

after.yaml

objectStorage:
  type: azureBlobStorage
  azureBlobStorage:
    container: develocity-application-data
    credentials:
      type: …
  monitoring:
    container: develocity-monitoring-data
    credentials:
      type: …

6.2. `monitoring` configuration when using embedded Object Storage

The new gradle-monitoring component stores its data in the embedded Object Storage if you don’t configure an user-managed Object Storage. After the installation, the embedded Object Storage volume size will be automatically increased by 20Gi. You can modify this behaviour by changing the following part of the values.yaml:

values.yaml

objectStorage:
  type: "embedded"
  embedded:
    storage:
      monitoring:
        capacity: 20Gi  # Capacity offered to the data hosted for the monitoring component.
                        # Default set to 20Gi.

The current default configuration is set to 20Gi, and this should be enough for most installations.

6.3. Extra container resources

With two new containers running in gradle-monitoring, the component requires more CPU and memory to run: See the default values for each in the following values.yaml example:

values.yaml

monitoring:
  metrics:
    scraper:
      resources:               # Controls resources allocated to the metrics scraper container (alloy).
        limits:
          cpu: 500m            # The default is 250m.
          memory: 1024Mi       # The default is 768Mi.
        requests:
          cpu: 500m            # The default is 250m.
          memory: 921Mi        # The default is 691Mi, 10% smaller than limits.

    database:
      resources:               # Controls resources allocated to the metrics database container (mimir).
        limits:
          cpu: 1000m           # The default is 500m.
          memory: 921Mi        # The default is 768Mi.
        requests:
          cpu: 1000m           # The default is 500m.
          memory: 921Mi        # The default is 691Mi, 10% smaller than limits.

You can modify and use this values.yaml during installation or upgrade to modify resource allocation for each container of this deployment.

6.4. `gradle-monitoring` extra Kubernetes capabilities

To operate, the gradle-monitoring component requires extra capabilities and access to the Kubernetes API. This is materialized by an extra Role (named develocity-monitoring) and RoleBinding (named develocity-monitoring) associated with the gradle-monitoring service account.

These extra capabilities are limited to the Develocity’s namespace only, and they are used solely to collect runtime data for better investigation during support.

6.5. `gradle-enterprise-operator` requires access to the Object Storage

As part of the support-bundle generation, the gradle-enterprise-operator requires access to the Object Storage, and specifically the one configured in objectStorage.<object-storage-of-your-choice>.monitoring.

Please configure and adjust your system to make the communication possible between this component and your configured object-storage (network rules, authentication, authorization…).

6.6. Access Key Expiration and Rotation

Develocity 2025.1 introduces the ability for access keys to expire automatically based on age. By default, access key expiration is enabled with a maximum lifespan of 365 days.

6.6.1. Plan for Access Key Rotation

To prevent service disruptions, it is essential to plan for the regular rotation of your access keys before their expiration dates. This involves creating new access keys and updating your services (such as CI/CD pipelines, Develocity Reporting Kit, and automated Develocity API processes) to use the new keys before the old ones expire.

6.6.2. Configure Your Desired Access Key Expiration Policy

If you wish to maintain the previous behavior where access keys do not automatically expire, you can disable this policy by setting accessControl.accessKeys.maxLifespan.enabled: false in your values.yaml file.

This value should be set before upgrading to Develocity 2025.1; otherwise, an expiration date will be applied to all existing access keys upon upgrade.

You can customize the maximum lifespan for access keys by setting accessControl.accessKeys.maxLifespan.duration in your values.yaml file.

6.7. Role Fix for User-Managed Databases

A bug was identified in the Develocity 2024.3.x database setup script for an external database resulted in the database superuser being granted the role of the two created login users, ge_app and ge_migrator.

This issue only affected Postgres versions 16 and higher. While generally not problematic, on AWS RDS and Aurora databases utilizing IAM credentials, this could make the superuser account used for running the script inaccessible via password credentials. The database setup script for Develocity 2025.1 and subsequent versions will now revoke these unintended role grants. Installations relying on these roles for superuser connections via IAM credentials may experience errors. To restore the superuser’s ability to use IAM credentials, the rds_iam role must be granted directly, as outlined in the AWS documentation.

6.8. Helm value `global.openshiftInstallation` deprecation

For security reasons, all Develocity pods (except gradle-database pod), are using user 65532 and group 65532, aka nonroot. This change is not compatible with the manifests generated using global.openshiftInstallation: true configuration.

This value is, therefore, deprecated and, if set, only accepts false as a value. Otherwise, the installation will fail. This is to notify the operator to set the Security Context Constraints to nonroot-v2 for all Develocity service accounts.

We invite you to remove global.openshiftInstallation entry from your configuration and apply the security constraint using one of the methods described below:

$ NAMESPACE=«your-namespace»
  for serviceaccountname in $(oc get serviceaacount -n $NAMESPACE -l "app.kubernetes.io/part-of=gradle-enterprise" -o jsonpath='{.items.*.metadata.name}');
  do
    oc adm policy add-scc-to-user nonroot-v2 --namespace $NAMESPACE -z $serviceaccountname
  done

Or by applying the following YAML manifest to the namespace:

role-bindings-for-openshift.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: system:openshift:scc:nonroot-v2
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:openshift:scc:nonroot-v2
subjects: (1)
- kind: ServiceAccount
  name: gradle-database
- kind: ServiceAccount
  name: gradle-enterprise-app
- kind: ServiceAccount
  name: gradle-enterprise-app-background-processor
- kind: ServiceAccount
  name: gradle-keycloak
- kind: ServiceAccount
  name: gradle-metrics
- kind: ServiceAccount
  name: gradle-monitoring
- kind: ServiceAccount
  name: gradle-embedded-object-storage
- kind: ServiceAccount
  name: gradle-enterprise-operator
- kind: ServiceAccount
  name: gradle-proxy
- kind: ServiceAccount
  name: gradle-enterprise-operator
- kind: ServiceAccount
  name: gradle-test-distribution-broker

1	Represent the list of `ServiceAccount` used by Develocity. This list may vary based on features you turn on or off

6.9. Helm values `[component].serviceAccount.annotations` deprecation

enterprise, enterpriseBackgroundProcessor and monitoring component specific annotations for the value serviceAccount.annotations are deprecated. Please remove any usage from your configuration and use the serviceAccountAnnotations value in database and objectStorage section instead. This ensures that all components that use the database or Object Storage are annotated consistently.

The following example shows how to migrate from the deprecated serviceAccount.annotations to the new serviceAccountAnnotations value.

before.yaml

enterprise:
...
  serviceAccount:
    annotations:
      "eks.amazonaws.com/role-arn": "arn:aws:iam::111122223333:role/iam-role-name"
...

after.yaml

database:
  location: user-managed
...
  credentials:
    type: irsa
    irsa:
      serviceAccountAnnotations:
      "eks.amazonaws.com/role-arn": "arn:aws:iam::111122223333:role/iam-role-name"
...

For more details about the available configuration options, please consult the Kubernetes Helm Chart Configuration Guide for Object Storage, the Kubernetes Helm Chart Configuration Guide for user-managed Database or the Standalone Helm Chart Configuration Guide for Object Storage and Standalone Helm Chart Configuration Guide for user-managed Database, based on your installation type.

6.10. Increased CPU resource usage

6.10.1. Increased resource usage for syslog-bridge in gradle-proxy pod

Due to continued CPU throttling issues with the syslog-bridge container, the default resource requests and limits for the container in the gradle-proxy pod have been increased. The new default values are 200m CPU for both (was 50m).

6.10.2. Increased resource usage for gradle-enterprise-operator in gradle-enterprise-operator pod

To improve the startup time of the gradle-enterprise-operator container, the default resource requests and limits for the container in the gradle-enterprise-operator pod have been increased. The new default values are 1 CPU for requests and 2 CPUs for limits (was 500m and 750m).

Appendix B: Upgrade command

The helm upgrade command is used to upgrade an existing release. It has several flags that control how the values are used for the upgrade. Specifically, the —-reuse-values and —-reset-values flags modify the behavior around the values passed to the upgrade.

--reuse-values: Keeps existing values and allows the setting of additional values.
--reset-values: Discards any previously set values and requires all values to be set.

Both flags give you fine-grained control over how values are managed during an upgrade, depending on whether you want to preserve or reset your previous configurations.

For more information about the helm upgrade command, refer to the official Helm documentation.

6.B.1. No changes

Use case: You want to upgrade but keep all the values from the current deployment without any modifications.

This is useful to ensure that existing values remain unchanged during an upgrade.
This is the most straightforward option if no configuration needs to be modified.

$ helm upgrade \
    --namespace develocity \(1)
    --reuse-values \(2)
    --version 2025.1.1 (3)
    ge \(4)
    gradle/gradle-enterprise \(5)

1	The namespace used to install Develocity
2	Reuse the configuration from the current deployment without any modifications
3	The Develocity version. If omitted, the latest version will be installed
4	The release name
5	The chart name (or archive if using a local chart)

6.B.2. Simple changes

Use case: You have an existing configuration and want to update the license value and disable ingress SSL, but keep the rest of the configuration.

$ helm upgrade \
    --namespace develocity \(1)
    --reuse-values \(2)
    --set-file global.license.file=./develocity.license \(3)
    --set ingress.ssl.enabled=false \(4)
    --version 2025.1.1 \(5)
    ge \(6)
    gradle/gradle-enterprise (7)

1	The namespace used to install Develocity
2	Reuse the configuration from the current deployment without any modifications
3	The path to the new license file
4	Disable the Ingress SSL
5	The Develocity version. If omitted, the latest version will be installed
6	The release name
7	The chart name (or archive if using a local chart)

This method works correctly only if you add new values or override existing values.
It won’t remove any previously set values, so that you may have a corrupted configuration.

Example:

previously-applied-config.yaml

objectStorage:
  type: s3
  s3:
    bucket: example-bucket
    region: example-aws-region-1
    credentials:
      source: environment

new-config.yaml

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

Upgrade command:

$ helm upgrade \
    --namespace develocity \
    --reuse-values \(1)
    --values new-config.yaml \(2)
    --version 2025.1.1 \
    ge \
    gradle/gradle-enterprise

1	Reuse the configuration from the current deployment without any modifications
2	Additionally, apply the partial configuration from the new-config.yaml file

We expect the source: environment to be removed and the type: instanceProfile to be added, but the result is different:

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

The application throws an error since the old configuration block is no longer supported, but it’s still present.

UPGRADE FAILED: execution error at (gradle-enterprise/templates/enterprise-app/deployment.yaml:3:3):
The `objectStorage.s3.credentials.source` attribute was removed.
Please use `objectStorage.s3.credentials.type instead.

The old attribute isn’t ignored during the upgrade process to quickly detect misconfigurations.

6.B.3. Complex changes

The --reset-values flag will discard all the values from the previous configuration.

Helm will use the default values defined in the chart during the upgrade, and any custom values previously set (whether through --set, --set-file, --values, or from the original release) will be ignored unless explicitly provided during the upgrade.

Use case: You want to upgrade to Develocity 2025.1 and adjust the Object Storage configuration (see the example above).

$ helm upgrade \
    --namespace develocity \(1)
    --reset-values \(2)
    --values values.yaml \(3)
    --set-file global.license.file=./develocity.license \(4)
    --version 2025.1.1 (5)
    ge \(6)
    gradle/gradle-enterprise \(7)

1	The namespace used to install Develocity
2	Discard old configuration settings
3	The path to the entire configuration file. No settings are preserved from the previous configuration
4	The path to the Develocity license file (if not included in values.yaml)
5	The Develocity version. If omitted, the latest version will be installed
6	The release name
7	The chart name (or archive if using a local chart)

Develocity Upgrade Guide

Install the container-selinux package

Install the `container-selinux` package