Develocity is a Kubernetes-based application, distributed as a Helm chart. Helm is a package manager for Kubernetes applications.
Helm manages all Develocity components.
Helm Overview
To use Helm, users must first import a Helm chart. A Helm chart is a Kubernetes manifest template, with variables that can be provided at installation time.
Providing Configuration to Helm
Helm uses a values.yaml
file to populate these variables and generate the Kubernetes manifests.
The variables in values.yaml
configure the Develocity installation with information such as networking, database, or hostname settings.
Here is a sample values.yaml
file:
global:
hostname: develocity.example.com
database:
type: embedded
ingress:
enabled: true
Helm configuration can be provided in several ways:
-
Passing values directly to the
helm
command using--set
or--set-file
. -
Creating a Helm values file and passing it to
helm
using--values
.
Once your values.yaml
file is complete, you will install Develocity using a command similar to the one below:
helm install --values ./values.yaml
Unless otherwise indicated, most values are optional and have usable defaults. |
Example Helm Values File
A complete example of the values file can be found here.
Considerations
Each section below contains an overview of Develocity installation options and their corresponding values.yaml
variables:
-
Global Options (Hostname, License)
-
Horizontal Scaling Options
-
Database Type (Embedded or External)
-
Storage Settings
-
Routing Options (Ingress or OpenShift)
-
Networking Options (Ports, Proxies, SSL)
-
Object Storage
-
Unattended Configuration
-
Using an external Bazel cache
For installations on hosts with limited to no network connectivity, see the additional section:
-
Airgap Installation
By the end of this guide, you will have a complete values.yaml
file, ready for your Develocity installation with storage, networking, database settings, and more.
Helm Options
1. Global Options
Hostname
When installing Develocity, you will need to provide a hostname such as develocity.example.com
.
This should be the hostname that users of the installation use to access it and therefore should resolve within your network. It is usually the name of the Develocity host or the hostname of a reverse proxy if one is being used.
Develocity will only accept requests with this hostname in their Host header. |
A hostname for the application is supplied in the Helm values file as follows:
global:
hostname: develocity.example.com
License
You have been provided with a Develocity license file called develocity.license
.
This file can be used in any testing, staging or production deployments of Develocity.
Only the "data" portion of the license is needed in the Helm value file, but it is acceptable to include the entire license file contents:
global:
license:
file: R0VMRgF4nBWOSZKCMAAAX+QUu3BUIJAIwUQiwsViEwMIDKOyvH701n3p6nJBYxoRHnAUnwHwKLjb...
The license file can also be supplied as a helm argument using --set-file . |
It is also possible to specify the license file as a Kubernetes secret. This can then be managed manually, or by tooling such as Sealed Secrets or AWS Secrets Manager.
To manually create a secret with the Develocity license:
$ kubectl create secret generic my-example-license-secret --from-file=license=path/to/develocity.license
Then configure Helm with the name of the secret:
global:
license:
secretName: my-example-license-secret
When specifying the license as a secret, an image pull secret must also be specified.
If performing an airgap installation, an image pull secret must be supplied anyway if the internal registry requires authentication.
If performing an online installation, the license file also needs to be created as an image pull secret:
$ kubectl create secret docker-registry my-example-license-image-pull-secret \
--docker-username=ignored \
"--docker-password=$(cat ./enterprise/internal-installs/develocity.license)" \
--docker-server=registry.gradle.com
global:
image:
imagePullSecret: my-example-license-image-pull-secret
2. Horizontal Scaling Options
A number of Develocity components can be scaled horizontally to provide greater performance and higher availability.
global:
scaling:
replicas: 2
Develocity’s scalable components are implemented as Kubernetes Deployment
resources. It is also possible to alter their replica count directly using kubectl scale
, allowing integration with other Kubernetes tooling.
It is only recommended to alter the replica count directly when connecting to a user-managed database, as available embedded database connections are configured based on the replica count. The user-managed database should have (160 ✖️ replica count) connections available.
3. Database Options
Develocity can store data in either:
-
An embedded database that uses a local directory or volume to store its data.
-
A user-managed database that is completely separate from Develocity.
There are tradeoffs to consider for each option:
Embedded database tradeoffs
When using the embedded database, Develocity will run a PostgreSQL database in a container and store data in a persistent volume. In this mode Develocity can run backups on a regular or cron-like schedule.
The embedded database has several advantages:
-
Simple setup with no additional configuration needed.
-
Automatic updates to the latest PostgreSQL version supported.
-
Features that require disk space information are supported.
-
Typically more affordable for smaller installations.
However, there are downsides to the embedded database, in particular for larger installations:
-
Disk I/O throughput can be a bottleneck on a busy system and is difficult to address.
-
Backup management is slow for larger databases, creates a load on the server, and consumes a lot of memory.
-
It is not possible to keep a standby database.
-
The database is a single point of failure.
User-managed database tradeoffs
A user-managed database can be any PostgreSQL 12, 13, or 14 compatible database.
There are a number of advantages, particularly in large installations:
-
Database customizations and optimizations are possible (memory, CPU, I/O throughput, etc…).
-
Resources can be allocated for cost-effectiveness.
-
Third party tools to snapshot the database can be used.
-
Many cloud databases allow for easy scaling of resources post installation.
-
A standby database for fail-over protection can be used.
There are some downsides to using a user-managed database:
-
Extra system(s) are needed for provisioning and configuration.
-
Database connectivity and network latency is a factor.
-
Backups must be managed by an administrator or a tool.
-
Disk space management and alerting are required.
-
Develocity features related to disk space are not available.
-
Security considerations such as credential cycling must be considered.
-
Customer support may be limited for disaster recovery or backup restores.
By default, Develocity will use an embedded database that stores its data in a persistent volume provided by the cluster. For this configuration, no additional values are needed in the Helm values file.
User-managed database configuration
When Develocity is configured to store data in a user-managed database, it must be provided with connection settings and credentials for the database.
Connection settings
These can be provided either to Helm as configuration or as Kubernetes ConfigMap
and Secret
resources. Configuring these in Helm is the simplest approach during installation. Providing these values via external Kubernetes resources allows performing update (e.g. changing credentials) without having to rerun helm
, and allows integration with other Kubernetes tooling (e.g. for Secret
provisioning).
Standard connection settings like host, port and database name must be provided. Optionally, additional JDBC parameters can be specified.
database:
location: user-managed
connection:
host: database.example.com
port: 5432
databaseName: gradle_enterprise
params: "?connectTimeout=60"
These can also be provided as a ConfigMap
. The name of the ConfigMap
must be provided, and the resource itself must be created prior to starting Develocity.
database:
location: user-managed
connection:
configMapName: my-example-db-connection-details
The ConfigMap
is then configured like this:
---
apiVersion: v1
kind: ConfigMap
metadata:
name: my-example-db-connection-details
data:
host: database.example.com
port: 5432
dbname: gradle_enterprise
jdbcParams: "?connectTimeout=60"
The port
, dbname
and jdbcParams
properties are all optional. The default database name is gradle_enterprise
.
The database must have already been created using CREATE DATABASE
, the createdb
command or an equivalent mechanism in a cloud database interface prior to configuring Develocity with connection details.
Credentials
There are three options for credentials:
Option 1 - superuser
If provided with credentials for a database superuser (such as the postgres
user that is common on PostgreSQL database instances), Develocity can perform the database setup.
A superuser can be added to the values file in the database section:
database:
location: user-managed
connection: ...
credentials:
superuser:
username: postgres
password: the_password
In some installations, often cloud-based, the default credentials provided are not a superuser. For example, the supplied postgres account in Amazon RDS Postgres databases is not a superuser, but has the rds_superuser role. Such accounts are typically acceptable to use with Develocity. |
These credentials can also be supplied as a Kubernetes Secret
:
database:
location: user-managed
connection: ...
credentials:
superuser:
secretName: my-example-db-superuser-credentials
The Secret
should have the typical username
and password
keys, encoded using Base64:
---
apiVersion: v1
kind: Secret
metadata:
name: my-example-db-superuser-credentials
data:
username: "cG9zdGdyZXM="
password: "ZXhhbXBsZS1wYXNzd29yZA=="
Option 2 - no superuser
To set up your database without database superuser credentials, run the setup.sh
script from the database setup scripts for your Develocity version against it. The script will set up less privileged accounts for the application to use, and some privileged functions needed for the application to run.
The installation will fail if you do not run the database setup scripts. |
The credentials for the accounts must be set by you and provided to Develocity via Helm configuration or Secrets.
To set up your database without database superuser credentials, the values file must be updated as follows:
database:
location: user-managed
connection: ...
credentials:
app:
password: app_password
migrator:
password: migrator_password
These credentials can also be supplied as Secret
resources. There are two accounts that must be configured, requiring a Secret
each.
database:
location: user-managed
connection: ...
credentials:
app:
secretName: my-example-db-application-credentials
migrator:
secretName: my-example-db-migrator-credentials
In this example stringData
is used (which does not require Base64 encoding) to show the correct usernames to use. The usernames are currently not configurable.
---
apiVersion: v1
kind: Secret
metadata:
name: my-example-db-application-credentials
stringData:
username: ge_app
password: "app-example-password"
---
apiVersion: v1
kind: Secret
metadata:
name: my-example-db-migrator-credentials
stringData:
username: ge_migrator
password: "migrator-example-password"
Option 3 - AWS IAM database authentication (with or without superuser)
Develocity can be configured to access the database by acquiring short-lived passwords dynamically using IAM database authentication, rather than using any stored password credentials. This makes it possible for you to manage access to the Develocity database without managing passwords directly. Using IAM database authentication requires that your database is an instance of either Amazon RDS or Amazon Aurora, and that your Develocity instance is running on Amazon EC2 instance(s) or running in an Amazon EKS cluster.
To configure Develocity to use IAM database authentication, your database credentials Helm config needs to include information about your database provider and how Develocity should acquire short-lived passwords. If you want Develocity to perform database setup automatically when starting, you also need to configure superuser access.
The Helm value database.provider
must be set to aws-rds
, and the Helm value database.credentials.type
must be set to either irsa
or instanceProfile
, where these two credentials types refer to EKS IAM roles for service accounts and EC2 instance profiles respectively. Both of these authentication implementations are described below.
Using EC2 instance profile credentials
Instance profile credentials can only be used if your Develocity installation is running on Amazon EC2 instance(s).
You must set up the appropriate permissions in AWS beforehand in order for Develocity to be able to acquire short-lived passwords using an EC2 instance profile. The steps to take this are described in the IAM database authentication for RDS section of our Amazon EC2 Standalone Installation Guide.
To configure Develocity to acquire short-lived database passwords using instance profile credentials, update your Helm values file as follows:
database:
location: user-managed
connection: ...
provider: aws-rds
credentials:
type: instanceProfile
Using EKS IRSA credentials
IRSA (IAM roles for service accounts) credentials can only be used if your Develocity installation is running in an Amazon EKS cluster.
You must set up the appropriate permissions in AWS beforehand in order for Develocity to be able to acquire short-lived passwords in this way. The steps to take this are described in the IAM database authentication for RDS section of our Amazon EKS Kubernetes Installation Guide.
When configuring Develocity to acquire short-lived passwords using IRSA authentication, specify the Helm value database.credentials.irsa.serviceAccountAnnotations
. By setting this Helm value, you can specify the EKS role annotation in one place, and the Develocity Helm chart will automatically take care of applying it to the Kubernetes service accounts which require it in the Develocity installation.
To configure Develocity to acquire short-lived passwords using IRSA credentials, update your Helm values file as follows:
database:
location: user-managed
connection: ...
provider: aws-rds
credentials:
type: irsa
irsa:
serviceAccountAnnotations:
eks.amazonaws.com/role-arn: «EKS role ARN» (1)
1 | Replace «EKS role ARN» with the ARN of an IAM role which can assume the required permissions. You can create such a role by following the instructions in the IAM database authentication for RDS section of our Amazon EKS Kubernetes Installation Guide. |
Database setup with IAM database authentication
Database setup must either be performed automatically by Develocity on startup by connecting to the database as a superuser, or it must be performed manually by you prior to installation by running the setup.sh
script from the database setup scripts for your Develocity version against the database.
If you want Develocity to be able to connect to the database as a superuser for automatic database setup, you need to provide either the username of a superuser (in which case Develocity will try to connect as the superuser using IAM authentication), or both the username and password of a superuser (in which case Develocity will try to connect as the superuser using the configured password). These can be provided directly using the Helm values database.credentials.superuser.username
and database.credentials.superuser.password
, or in a Kubernetes Secret, whose name must be provided in the Helm value database.credentials.superuser.secretName
and which contains either only a username
, or both a username
and a password
.
If you want to specify superuser credentials using a Kubernetes Secret, it should have the typical username
and password
keys, encoded using Base64:
---
apiVersion: v1
kind: Secret
metadata:
name: my-example-db-superuser-credentials
data:
username: "cG9zdGdyZXM="
password: "ZXhhbXBsZS1wYXNzd29yZA==" (1)
1 | Omit the 'password' field if you want Develocity to connect to the database using IAM authentication. |
4. Storage Settings
Storage Class Configuration
The Kubernetes StorageClass can be configured for data, logs and backup volumes. If omitted, the default storage class for the cluster will be picked, if there is one. Please consult your cluster documentation for available storage classes.
Not all clusters provide a useable default storage class. It’s strongly recommended to consult your cluster documentation and select from the available storage classes explicitly. |
global:
storage:
data:
class: some-provisioned-io-storage-class
backup:
class: slow-and-cheap-storage-class
Backup storage class is not necessary when connecting to a user-managed database. |
Storage Capacity Configuration
Develocity needs a certain amount of storage for data, logs and backups. If omitted, the shown default amount of storage will be requested from the cluster.
database:
storage:
data:
capacity: 1000Gi # default 250Gi
backup:
capacity: 1000Gi # default 250Gi
metrics:
storage:
data:
capacity: 1Gi # default 200Mi
testDistribution:
storage:
data:
capacity: 20Gi # default 10Gi
monitoring:
storage:
data:
capacity: 20Gi # Default 20Gi
objectStorage:
type: embedded
embedded:
storage:
data:
capacity: 20Gi # Default 10Gi
Backup storage capacity is not necessary when connecting to a user-managed database. |
5. Routing Options
There are a number of ways to route web traffic to Develocity from outside the Kubernetes cluster. These include:
-
An Ingress.
-
An OpenShift Route.
Which you choose to use will depend on your organizational policies and available infrastructure.
Supplied Ingress
Develocity can create a Kubernetes Ingress resource for you that is managed as part of your Helm release. The Ingress will be bound to the hostname that is configured.
ingress:
enabled: true
Your Ingress-Controller implementation has to be compatible with GRPC to support some Develocity features (e.g. Bazel Build Scans). For more details about this, please consult your Ingress-Controller implementation. |
User-managed Routing
For compatibility and configuration reasons, we strongly recommend to use the supplied Ingress definition. If the provided one is not suitable, you will need to provide your own configuration aligned with Develocity supplied Ingress.
Develocity creates a service named gradle-proxy
exposing ports 80
and 443
(when HTTPS is enabled, see below) for accessing the application. This is the service to which alternative routing infrastructure such as load balancers will need to route traffic.
You may need to configure your Ingress differently to support Bazel using GRPC . Contact Develocity Customer Support for help with Bazel and your own Ingress definition. |
OpenShift Configuration
Develocity needs to know when it is being deploying to an OpenShift cluster.
global:
openshiftInstallation: true
6. Networking Options
There are a number of considerations for Develocity related to connectivity:
-
HTTP or HTTPS (with SSL certificates)
-
GRPC
-
Application Ports
-
Proxies
HTTP or HTTPS
Develocity can be configured to securely serve traffic over HTTPS based on user-provided certificates.
If certificates are not supplied, self-signed certificates will be generated and used, though this is not recommended for production operation.
HTTPS Terminated at Ingress
When using the Develocity supplied Ingress, HTTPS is enabled by default.
It can be disabled to serve traffic over HTTP only:
ingress:
enabled: true
ssl:
enabled: false
SSL certificates (trusted or untrusted) can be provided inline in the values file:
ingress:
enabled: true
ssl:
cert: |
-----BEGIN CERTIFICATE-----
MIIDKjCCAhKgAwIBAgIRAPNTIHf6/oUuzMKm3ffGNOgwDQYJKoZIhvcNAQELBQAw
HDEaMBgGA1UEAxMRYXV0by1nZW5lcmF0ZWQtY2EwHhcNMjExMTMwMTU1NDU5WhcN
...
Cn/3yUirFVTslrSYKAemLw8btLO6FDF9dc/lq1o7tKsYVuhEcjqnTah7puJjEN9h
z+P5RmRxU/kaaFB+Vuw1pRezbaAtZNorVgXnBwrdseY4zLGyhAcGcR9v+VtCiQ==
-----END CERTIFICATE-----
key: |
-----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEA4qV8JlqDMi7y85Ykq8dn7uIsi609D6KuFtlc+UvNYjatz0+u
QzIr3iw//qf7sM8nx8fhGwuWvUWeCE6zbgKjuxDH82J9NQ0ctf70n0qVTeyW1CKR
...
XlOfXr/xvkXA66PROgvVxfwpN/GNrLXFi1HvMg7MVZJUZQpNzpAzw5JTk2MbawOl
G7tI0qQ6F20e5R4tPpEDKCFZykyvgGMhfLzsvVlrgaVW8QbVK4YWNtQ=
-----END RSA PRIVATE KEY-----
Or the certificate can refer to a Kubernetes TLS Secret already available in the cluster:
ingress:
enabled: true
ssl:
secretName: example-ssl-certificate-secret-name
HTTPS SSL Certificate
It is strongly recommended that production installations of Develocity are configured to use HTTPS with a trusted certificate.
Develocity natively supports serving traffic over HTTPS when configured with a certificate and key. If you intend to use an Ingress Controller for directing external traffic to Develocity, you may opt to terminate HTTPS there. It is also possible to terminate HTTPS connections in an external reverse proxy.
Untrusted SSL Certificates
By default, Develocity uses the default trust settings of the Java runtime that it ships with when connecting to other systems using SSL.
If your organization uses certificates that are not signed by a trusted certificate authority, you must perform additional configuration for this to work (see below). This may be the case if you use self-signed certificates or an internal certificate authority.
Additional Certificates
Additional trusted certificates for outbound traffic can be specified at installation time via the unattended configuration mechanism, using the additionalTrust
field in the unattended configuration file. The value of this field should be the X509 certificates to trust in PEM format, newline-separated if there are more than one.
For example, using the inline Helm values support to include the unattended configuration in a values file:
global:
unattended:
configuration:
version: 9
systemPassword: ...
network:
additionalTrust: |
-----BEGIN CERTIFICATE-----
MIIDfzCCAmegAwIBAgIURqPslYGu7cHXs22q3RK6e5L87PwwDQYJKoZIhvcNAQEL
...
s10yB5VjVBES6A22rYwYb8mImpQiVP/mr4ao5U5m+h50l3E=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
DSE3a3CCAmegAwIBAgIURqPslYGu7cHXs22q3RK6e5L87PwwDQYJKoZIhvcNAQEL
...
s10yB5VjVBES6A22rYwYb8mImpQiVP/mr4ao5U5m+h50l3E=
-----END CERTIFICATE-----
HTTPS Terminated Externally
In many setups, a reverse proxy or load balancer will perform SSL termination. In this case, SSL certificates must be configured accordingly.
Develocity needs to know that the application will be accessed over externally terminated HTTPS. This is done with the following configuration:
global:
hostname: develocity.example.com
externalSSLTermination: true
If you’re using the provided Ingress, you may wish to communicate between the load balancer and the application using HTTP by disabling SSL at the Ingress:
ingress:
enabled: true
ssl:
enabled: false
GRPC
Develocity uses the GRPC
protocol for Bazel
features. To support this, the application has to be exposed with grpc/http2
compatible components (e.g. Ingress-Controller, Firewall, Load balancers…).
Please consult the documentation of those infrastructure or Kubernetes components to get more information about support and requirements for grpc
compatibility. All examples below use example annotations that are not relevant for your installation.
GRPC with Ingress annotations
Some Ingress-Controller implementations require extra implementation-specific annotations on Ingress
objects to be compatible with grpc
. You can provide them using the following entry in the values.yaml
:
ingress:
enabled: true
grpc:
annotations:
acme.ingress.kubernetes.io/backend-protocol: "GRPC"
GRPC with Service annotations
Some Ingress-Controller implementations require extra implementation-specific annotations on Ingress
objects to be compatible with grpc
. You can provide them using the following entry in the values.yaml
:
ingress:
enabled: true
grpc:
serviceAnnotations:
acme.ingress.kubernetes.io/upstream-protocol.h2c: "grpc"
Application Ports
The ports that the application accepts traffic on can be altered from the default of 443 (or 80 if accepting plain HTTP) as follows:
ingress:
enabled: true
port:
http: 8080
https: 8443
Proxy Configuration
By default, Develocity requires an internet connection to make several outbound HTTP requests (such as license validation).
In case your organization requires all outbound HTTP traffic to go through an HTTP proxy, you must perform additional configuration for this to work.
HTTP proxy configuration can be specified under the network
section in the unattended configuration section:
global:
unattended:
configuration:
version: 9
systemPassword: ...
network:
proxy:
protocol: http (1)
host: proxy.gradle.com (2)
port: 8080 (3)
excludedHosts: (4)
- some.external
- '*.internal'
auth: (5)
username: proxy_user
password: "aes256:B0uVHRDhng+PraUI:2bOz71vKTexz0QH5:z7lO+1wOC/tA3izLAwV0BXMugg=="
1 | The protocol used to connect to the proxy. Note that this is not the protocol used to connect to the destination/target addresses. Supported values are http and https , if no value is provided http will be used as the default protocol. |
2 | HTTP proxy host name. |
3 | HTTP proxy port, if no value is provided 80 will be used ad the default port. |
4 | A comma-delimited list that controls what hosts should not be proxied. The list can contain individual host names as well as domain patterns (e.g. '*.internal') which match all hosts for a particular domain. Any requests sent to these hosts will be sent directly rather than being sent through the HTTP proxy. |
5 | A username and password used to authenticate with the HTTP Proxy. |
7. Object Storage Configuration
Develocity can store two kinds of data in a user-managed object storage service, such as Amazon S3:
-
Build Scan data is stored in the database by default, but Develocity can be configured to store Build Scans in an object store instead.
-
Build Cache data is stored in embedded object storage - a persistent volume backed server installed with Develocity - by default, but can be configured to store Build Cache data in a user-managed object store instead.
The Build Scan object storage section of the Administration Manual discusses the tradeoffs of using object storage rather than a database for Build Scan data. We recommend that your object storage is hosted close to your Develocity installation to minimise latency and network usage costs. For example, if using S3 as an object storage service, verify that your S3 bucket and Develocity installation reside in the same AWS region.
Most popular object storage services are supported. Alternatively, Develocity ships with the ability to run an embedded object store as one of its components. The rest of this section describes how to configure Develocity to use AWS S3, an S3-compatible object storage service, Google Cloud Storage, Microsoft Azure Blob Storage, or the embedded object storage.
To finish configuring Develocity to store Build Scan data in the configured object storage, you must also configure Develocity with an unattended configuration stanza in your Helm values.yaml file. See Objects Storage for Build Scans for details. |
If Develocity is connected to a user-managed object storage service, then Develocity will switch to storing Build Cache data there, instead of embedded object storage. |
Amazon S3
The S3 object storage section of the Amazon EKS Installation Guide describes steps for setting up a bucket in S3 with an appropriate access policy.
To use Amazon S3 as the object store for Develocity, you need to set the type of the object storage as s3
and configure the bucket name and region.
objectStorage:
type: s3
s3:
bucket: example-bucket (1)
region: example-aws-region-1 (2)
credentials:
#...
1 | Your S3 bucket name. |
2 | The cloud provider region where your object storage resides. |
It is necessary to provide credentials to access the bucket. There are several options to do this as documented below.
If Develocity is hosted on AWS, it is strongly recommended to set up and configure access to the S3 bucket via a VPC endpoint to reduce access cost and latencies. Refer to the official AWS VPC endpoint documentation to learn more. |
IAM Roles for Service Account credentials configuration
You can provision credentials to Develocity dynamically using IAM Role for Service Account.
objectStorage:
type: s3
s3:
bucket: example-bucket
region: example-aws-region-1
credentials:
type: irsa
irsa:
serviceAccountAnnotations:
"eks.amazonaws.com/role-arn": arn:aws:iam::«account-id»:role/«role-name»
Keys credentials configuration
To provide an access key and secret key as credentials in the Helm chart, set type
to keys
and provide the accessKey
and secretKey
.
objectStorage:
type: s3
s3:
bucket: example-bucket
region: example-aws-region-1
credentials:
type: keys
keys:
accessKey: "AKIA1234ABCD7890"
secretKey: "dfml3s9rfdlsok390wledck30rkdfs"
Keys credentials configuration via Kubernetes secret
To provide an access key and secret key stored in a Kubernetes secret as credentials, set type
to keys
and provide the secretName
to the Kubernetes resource name of the secret. The secret must contain accessKey
and secretKey
properties.
objectStorage:
type: s3
s3:
bucket: example-bucket
region: example-aws-region-1
credentials:
type: keys
keys:
secretName: example-s3-credentials
apiVersion: v1
kind: Secret
metadata:
name: example-s3-credentials
stringData:
accessKey: "AKIA1234ABCD7890"
secretKey: "dfml3s9rfdlsok390wledck30rkdfs"
This option has the advantage of allowing credential cycling without needing to rerun Helm to reconfigure Develocity with the new credentials, and separating sensitive credentials from other settings. A manual pod restart is required to apply the new credentials.
kubectl rollout restart deployment --selector 'app.kubernetes.io/component in (enterprise-app, enterprise-app-background-processor)
Direct credentials configuration (Deprecated)
This configuration option is deprecated since 2024.2 and will be removed in a future release. Please use Keys credentials configuration instead.
To provide an access key and secret key as credentials in the Helm chart, set source
to configuration
and provide the accessKey
and secretKey
.
objectStorage:
type: s3
s3:
bucket: example-bucket
region: example-aws-region-1
credentials:
source: configuration
accessKey: "AKIA1234ABCD7890"
secretKey: "dfml3s9rfdlsok390wledck30rkdfs"
Credentials configuration via Kubernetes secret (Deprecated)
This configuration option is deprecated since 2024.2 and will be removed in a future release. Please use Keys credentials configuration via Kubernetes secret instead.
To provide an access key and secret key stored in a Kubernetes secret as credentials, set the secretName
to the Kubernetes resource name of the secret. The secret must contain accessKey
and secretKey
properties.
objectStorage:
type: s3
s3:
bucket: example-bucket
region: example-aws-region-1
credentials:
secretName: example-s3-credentials
apiVersion: v1
kind: Secret
metadata:
name: example-s3-credentials
stringData:
accessKey: "AKIA1234ABCD7890"
secretKey: "dfml3s9rfdlsok390wledck30rkdfs"
Credentials sourced from the execution environment (Deprecated)
This configuration option is deprecated since 2024.2 and will be removed in a future release. Please use IAM Roles for Service Account credentials configuration instead.
It is possible to provision credentials to Develocity dynamically using EC2 instance profiles or EKS service accounts. Once these have been set up, set the credentials source
to environment
.
objectStorage:
type: s3
s3:
bucket: example-bucket
region: example-aws-region-1
credentials:
source: environment
Custom endpoint
There are circumstances in which it is necessary to specify the endpoint URL of the service:
-
If you need to connect to S3 directly from a VPC using a gateway VPC endpoint.
-
If your object storage service is not S3 but provides an S3-compatible interface.
To do this, set the endpoint
property to point to the service endpoint:
objectStorage:
type: s3
s3:
bucket: example-bucket
endpoint: https://object-store.example.com
credentials:
#...
Google Cloud Storage
To use Google Cloud Storage as the object storage, set the type
of object storage as googleCloudStorage
and configure the bucket
.
objectStorage:
type: googleCloudStorage
googleCloudStorage:
bucket: example-bucket
credentials:
#...
It is necessary to provide credentials to access the bucket. There are several options to do this as documented below.
Workload Identity Federation credentials configuration
You can provision credentials to Develocity dynamically using Workload Identity Federation.
objectStorage:
type: googleCloudStorage
googleCloudStorage:
bucket: example-bucket
credentials:
type: workloadIdentity
Service Account Key credentials configuration
To provide the service account key as credentials in the Helm chart, set type
to serviceAccount
and provide the key
.
objectStorage:
type: googleCloudStorage
googleCloudStorage:
bucket: example-bucket
credentials:
type: serviceAccount
serviceAccount:
key: |
{
"type": "service_account",
"project_id": "PROJECT_ID",
"private_key_id": "KEY_ID",
"private_key": "-----BEGIN PRIVATE KEY-----\nPRIVATE_KEY\n-----END PRIVATE KEY-----\n",
"client_email": "SERVICE_ACCOUNT_EMAIL",
"client_id": "CLIENT_ID",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://accounts.google.com/o/oauth2/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL"
}
Credentials configuration via Kubernetes secret
To provide a service account key stored in a Kubernetes secret as credentials, set type
to serviceAccount
and provide the secretName
to the Kubernetes resource name of the secret. The secret must contain serviceAccountKey
property.
objectStorage:
type: googleCloudStorage
googleCloudStorage:
bucket: example-bucket
credentials:
type: serviceAccount
serviceAccount:
secretName: example-gcs-credentials
apiVersion: v1
kind: Secret
metadata:
name: example-gcs-credentials
stringData:
serviceAccountKey: |
{
"type": "service_account",
"project_id": "PROJECT_ID",
"private_key_id": "KEY_ID",
"private_key": "-----BEGIN PRIVATE KEY-----\nPRIVATE_KEY\n-----END PRIVATE KEY-----\n",
"client_email": "SERVICE_ACCOUNT_EMAIL",
"client_id": "CLIENT_ID",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://accounts.google.com/o/oauth2/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL"
}
This option has the advantage of allowing credential cycling without needing to rerun Helm to reconfigure Develocity with the new credentials, and separating sensitive credentials from other settings. A manual pod restart is required to apply the new credentials.
kubectl rollout restart deployment --selector 'app.kubernetes.io/component in (enterprise-app, enterprise-app-background-processor)
Google Cloud Storage (Deprecated)
This configuration option is deprecated since 2024.2 and will be removed in a future release. Please use Google Cloud Storage instead.
To use Google Cloud Storage as the object storage, set the type
of object storage as googleCloud
and configure the bucket
.
objectStorage:
type: googleCloud
googleCloud:
bucket: example-bucket
credentials:
#...
Develocity accesses the GCS bucket using the Interoperability API. Access keys can be created in the Google Cloud console on the Cloud Storage Interoperability page. Once created, you must configure Develocity with the access key and secret key, as documented below.
Direct credentials configuration
To provide the access key and secret key as credentials in the Helm chart, set source
to configuration
and provide the accessKey
and secretKey
.
objectStorage:
type: googleCloud
googleCloud:
bucket: example-bucket
credentials:
source: configuration
accessKey: "GOOG1234ABCD7890"
secretKey: "dfml3s9rfdlsok390wledck30rkdfs"
Credentials configuration via Kubernetes secret
To provide an access key and secret key stored in a Kubernetes secret as credentials, set the secretName
to the Kubernetes resource name of the secret. The secret must contain accessKey
and secretKey
properties.
objectStorage:
type: googleCloud
googleCloud:
bucket: example-bucket
credentials:
secretName: example-gcs-credentials
apiVersion: v1
kind: Secret
metadata:
name: example-gcs-credentials
stringData:
accessKey: "GOOG1234ABCD7890"
secretKey: "dfml3s9rfdlsok390wledck30rkdfs"
Azure Blob Storage
To use Azure Blob Storage as the object storage, set the type
of the object storage as azureBlobStorage
and configure the container
name.
objectStorage:
type: azureBlobStorage
azureBlobStorage:
container: example-container
credentials:
#...
It is necessary to provide credentials to access the bucket. There are several options to supply these as documented below.
Workload Identity Federation credentials configuration
You can provision credentials to Develocity dynamically using Workload Identity Federation.
objectStorage:
type: azureBlobStorage
azureBlobStorage:
container: example-container
credentials:
type: workloadIdentity
Account Key credentials configuration
To provide an account name and key in the Helm chart, set type
to accountInformation
and provide the accountName
and accountKey
properties.
objectStorage:
type: azureBlobStorage
azureBlobStorage:
container: example-container
credentials:
type: accountInformation
accountInformation:
accountName: "example-account"
accountKey: "dfml3s9rfdlsok390wledck30rkdfs"
Credentials configuration via Kubernetes secret
To provide an account name and key credential stored in a Kubernetes secret, set type
to accountInformation
and provide the secretName
to the Kubernetes resource name of the secret. The secret must contain an accountName
and accountKey
.
objectStorage:
type: azureBlobStorage
azureBlobStorage:
container: example-bucket
credentials:
type: accountInformation
accountInformation:
secretName: example-azure-credentials
apiVersion: v1
kind: Secret
metadata:
name: example-azure-credentials
stringData:
accountName: "example-account"
accountKey: "dfml3s9rfdlsok390wledck30rkdfs"
This option has the advantage of allowing credential cycling without needing to rerun Helm to reconfigure Develocity with the new credentials, and separating sensitive credentials from other settings. A manual pod restart is required to apply the new credentials.
kubectl rollout restart deployment --selector 'app.kubernetes.io/component in (enterprise-app, enterprise-app-background-processor)
Azure Blob Storage (Deprecated)
This configuration option is deprecated since 2024.2 and will be removed in a future release. Please use Azure Blob Storage instead.
To use Azure Blob Storage as the object storage, set the type
of the object storage as azure
and configure the container
name.
objectStorage:
type: "azure"
azure:
container: example-container
credentials:
#...
It is necessary to provide credentials to access the bucket. Develocity supports two different mechanisms for supplying credentials:
-
Specify a single connection string
-
Specify a Shared Access Secret (SAS) and an endpoint for the Azure storage account.
There are several options to supply these as documented below.
Direct connection string configuration
To provide a connection string in the Helm chart, set source
to connectionString
and provide the connectionString
.
objectStorage:
type: azure
azure:
container: example-container
credentials:
source: connectionString
connectionString: "DefaultEndpointsProtocol=https;AccountName=exampleaccount;AccountKey=dfml3s9rfdl==;EndpointSuffix=core.windows.net"
Direct Session Access Signature configuration
To provide a SAS in the Helm chart, set source
to sas
and provide the sas
and endpoint
.
objectStorage:
type: azure
azure:
container: example-container
credentials:
source: sas
sas: "dfml3s9rfdlsok390wledck30rkdfs"
endpoint: https://exampleaccount.blob.core.windows.net
Credentials configuration via Kubernetes secret
To provide either above type of credential stored in a Kubernetes secret, set the secretName
to the Kubernetes resource name of the secret. The secret must contain either a connectionString
or a sas
and endpoint
pair.
objectStorage:
type: azure
azure:
container: example-bucket
credentials:
secretName: example-azure-credentials
apiVersion: v1
kind: Secret
metadata:
name: example-azure-credentials
stringData:
connectionString: "DefaultEndpointsProtocol=https;AccountName=exampleaccount;AccountKey=dfml3s9rfdl==;EndpointSuffix=core.windows.net"
apiVersion: v1
kind: Secret
metadata:
name: example-azure-credentials
stringData:
sas: "dfml3s9rfdlsok390wledck30rkdfs"
endpoint: "https://exampleaccount.blob.core.windows.net"
Embedded object Storage
Embedded object storage is a component that is deployed as part of the Develocity installation if no other object storage is configured.
The type
of the object storage is embedded
.
objectStorage:
type: embedded
Data will be stored on a persistent volume. See Storage Capacity Configuration for details on specifying the capacity of the embedded object storage.
Build Scans cannot be stored in embedded object storage. See the relevant section of the Administration Manual for more information on setting the storage type for incoming Build Scans using unattended configuration. |
Data in the embedded object store is not part of a Develocity database backup. |
Configuring advanced parameters
Each object storage provider can be further configured using advancedParams
. You should only configure advanced parameters if you have been directed to do so by Develocity support.
objectStorage:
type: s3
s3:
bucket: example-bucket
region: example-aws-region-1
credentials:
type: irsa
advancedParams:
client.maxConcurrency: 12
8. Unattended Configuration
Many aspects of Develocity’s behaviour can be configured via the Admin user interface or by providing an unattended configuration file. These settings are described in the unattended configuration section of the Develocity Administration Manual.
Unattended configuration settings can also be in their own yaml file and given to the helm command as follows: --set-file global.unattended.configuration=./unattended-config.yaml |
While most of Develocity can be configured post-installation, there are two items that can and should be configured at installation time:
-
Proxy settings
-
Object Storage for Build Scans
In order to use the unattended configuration in your Helm values file, you will need the hashed system user password and a configuration version. The Develocity Admin CLI must also be installed. Full instructions are available in the Administration Manual.
Having prepared a Develocity configuration file and optionally an encryption key, you can provide it to Helm in one of two ways.
Example key:
aes256:B0uVHRDhng+PraUI:Aj25DOwJsrXnWYcprreHAS4l66k/7q5CIjFDg5PTR7U=
Example yaml file:
version: 9
systemPassword: "ObvvvqQww04Fn2jLBOOgjZDkXGL06fNmpueVcdk1lz0=:dBLNuLA/+qiwOqBQKf5pW89SV5mcQBJ4Vph/7lXerdD+2sLM8jij+2WJbBwXsqJ+mJugsveuUb+DyU3LBgkqcg=="
buildScans:
keepDays: 30
email:
administratorAddress: develocity-adminstrator@example.com
fromAddress: develocity@example.com
smtpServer: smtp.example.com:587
sslProtocol: startTls
authentication:
type: login
username: develocity-adminstrator@example.com
password: "aes256:B0uVHRDhng+PraUI:2bOz71vKTexz0QH5:z7lO+1wOC/tA3izLAwV0BXMugg=="
The file and encryption key can be provided inline in a Helm values file under the global.unattended
property:
global:
unattended:
key: "aes256:B0uVHRDhng+PraUI:Aj25DOwJsrXnWYcprreHAS4l66k/7q5CIjFDg5PTR7U=" (1)
configuration: (2)
version: 9
systemPassword: "ObvvvqQww04Fn2jLBOOgjZDkXGL06fNmpueVcdk1lz0=:dBLNuLA/+qiwOqBQKf5pW89SV5mcQBJ4Vph/7lXerdD+2sLM8jij+2WJbBwXsqJ+mJugsveuUb+DyU3LBgkqcg=="
buildScans:
keepDays: 30
email:
administratorAddress: develocity-adminstrator@example.com
fromAddress: develocity@example.com
smtpServer: smtp.example.com:587
sslProtocol: startTls
authentication:
type: login
username: develocity-adminstrator@example.com
password: "aes256:B0uVHRDhng+PraUI:2bOz71vKTexz0QH5:z7lO+1wOC/tA3izLAwV0BXMugg=="
1 | The encryption key used for any secrets in your configuration. In this example, the password for email authentication is encrypted. Not required if the configuration does not contain any encrypted passwords. Note that the systemPassword is a hashed value, not an encrypted one, and so does not require an encryption key. |
2 | The Develocity configuration yaml is put inline underneath this property. Content needs to be indented such that it is all correctly under the global.unattended.configuration property. |
Or they can be supplied as helm
arguments using --set-file
:
$ (helm command) \
--set-file global.unattended.configuration=path/to/develocity-configuration.yaml \
--set-file global.unattended.key=path/to/develocity-configuration.key
Develocity configuration that is set in Helm like this will not be reapplied (i.e. overwrite manual changes made in the Admin UI) in subsequent installations unless the contents of the config file(s) has changed. |
Proxy Settings
HTTP proxy configuration can be specified under the network
section in the unattended configuration section:
global:
unattended:
configuration:
version: 9 (1)
systemPassword: "«hashed-system-password»" (2)
network:
proxy:
protocol: http (3)
host: proxy.gradle.com (4)
port: 8080 (5)
excludedHosts: (6)
- some.external
- '*.internal'
auth: (7)
username: proxy_user
password: "aes256:B0uVHRDhng+PraUI:2bOz71vKTexz0QH5:z7lO+1wOC/tA3izLAwV0BXMugg=="
1 | The version of the unattended config. See the Administration Manual. |
2 | The hashed system user password. See the Administration Manual. |
3 | The protocol used to connect to the proxy. Note that this is not the protocol used to connect to the destination/target addresses. Supported values are http and https , if no value is provided http will be used as the default protocol. |
4 | HTTP proxy host name. |
5 | HTTP proxy port, if no value is provided 80 will be used ad the default port. |
6 | A comma-delimited list that controls what hosts should not be proxied. The list can contain individual host names as well as domain patterns (e.g. '*.internal') which match all hosts for a particular domain. Any requests sent to these hosts will be sent directly rather than being sent through the HTTP proxy. |
7 | A username and password used to authenticate with the HTTP Proxy. |
Objects Storage for Build Scans
To configure Develocity to store incoming Build Scan data using your object storage service bucket or container, add the following to your Helm values file:
global:
unattended:
configuration:
version: 9 (1)
systemPassword: "«hashed-system-password»" (2)
buildScans:
incomingStorageType: objectStorage
advanced:
app:
heapMemory: 5632 (3)
objectStorage: (4)
type: s3
s3:
bucket: example-bucket
region: «region»
credentials:
type: irsa
1 | The version of the unattended configuration. See the Administration Manual. |
2 | Your hashed system password. See the Administration Manual. |
3 | If you have already set a custom value here for heap memory, increase it by 2048 . |
4 | The object storage stanza you created in 7. Object Storage Configuration. If you set incomingStoragetype to objectStorage , then you must configure an object storage service with this stanza in values.yaml for your Develocity instance. |
This example uses S3 with environment-source credentials, but your object storage configuration may be different.
9. Using an external Bazel cache
If you wish to use Build Scans for your Bazel builds while using a remote cache other than the one built into Develocity, you will need to configure the necessary details. Please note that your remote cache must expose a GRPC endpoint for Develocity to be able to speak to it.
The only mandatory value is the host and port of your external cache:
enterprise:
bazel:
remoteCacheConnection:
url: grpc{s}://<hostname>:<port>
If your external cache allows anonymous reads, this is the only value you need. Otherwise, see the section on authentication.
Trusting a server certificate
See the section on Untrusted SSL certificates.
Authenticating to an external Bazel cache
All configuration of authentication to a Bazel cache will take the following form:
enterprise:
bazel:
remoteCacheConnection:
url: grpc{s}://<hostname>:<port>
authType: <AUTH_TYPE>
auth:
<AUTH_TYPE>:
...
Please note that any credentials you provide must allow a user to read from the cache.
The following authentication methods are currently supported:
Bearer token authentication
In this authentication method, an external token will be passed to the server in the Authorization header prefixed by "Bearer" - Bearer <token>
. The configuration for this scenario should look like this:
enterprise:
bazel:
remoteCacheConnection:
url: grpc{s}://<hostname>:<port>
authType: bearerToken
auth:
bearerToken:
token: <TOKEN>
TLS client authentication
In this authentication method, a client certificate + key will be used to authenticate to the cache. Please note that the certificate and key must be separate values and in PEM format. You can provide these values directly, in which case the configuration looks like this:
enterprise:
bazel:
remoteCacheConnection:
url: grpc{s}://<hostname>:<port>
authType: tls
auth:
tls:
cert: |-
<PEM_FORMATTED_CERT>
key: |-
<PEM_FORMATTED_KEY>
If you do not wish to include these values in your YAML file, you may create a TLS Secret in your cluster in the same namespace where you are installing Develocity and then pass in the name of that secret:
enterprise:
bazel:
remoteCacheConnection:
url: grpc{s}://<hostname>:<port>
authType: tls
auth:
tls:
secretName: <SECRET_NAME>
10. Airgap Installations
Develocity can be run on hosts without internet connectivity, referred to as an airgap installation.
Airgap Configuration
In an airgap installation, Helm is configured so that no attempt is made to pull images from the outside world with the values below:
global:
image:
imagePullPolicy: Never
Your values.yaml
file is complete. You can return to the installation manual.
Changing Configuration Values
To change configuration values without changing the version of Develocity, you need to specify the current installed Develocity version.
It’s important to specify the Develocity version, because if you don’t, you may accidentally install a newer version and initiate an upgrade rather than merely a configuration change. Such accidental upgrades may be irreversible. |
To check the deployed Develocity version, run:
$ helm history --namespace develocity ge --max 1
To apply new configuration values to a Helm-managed online installation, run:
$ helm upgrade \
--namespace develocity \
ge gradle/{chartName} \
--version «deployed-version» \(1)
--reuse-values \
«new values options»
1 | «deployed-version» is the deployed version of Develocity. |
Or for a Helm-managed airgap installation:
$ helm upgrade \
--namespace develocity \
ge {chartName}-«deployed-version».tgz \(1)
--version «deployed-version» \
--reuse-values \
«new values options»
1 | «deployed-version» is the deployed version of Develocity. |
The above examples reuse previous values by default. Any specified values will override the existing values.
If you want to specify all values explicitly (ignoring any previously set values), run with --reset-values
instead of --reuse-values
.
Watch Out
Running |
Configuration values are provided to Helm when running the helm
command by:
-
Providing a Helm values file (which can contain inline files) with
--values
-
Providing files (such as the Develocity license or certificates) with
--set-file
If you have made local modifications to a Helm values file, apply the changes to your installation by running an upgrade command (see above) with a --values «updated-values-file»
option.
If you have made local modifications to a file you previously provided via --set-file
, apply the changes to running an upgrade command (see above) with a --set-file
option.
Appendix A: Background Processing Configuration
Depending on the volume and frequency of your builds, background tasks for newly uploaded Build Scans can require a significant amount of CPU and memory. Moreover, some upgrades or configuration changes of Develocity require reprocessing existing builds to extract new data. For example, when enabling Predictive Test Selection for the first time all existing builds will be processed to collect change and test execution history.
Therefore, background work can optionally be processed in a separate pod that can be scaled independently of other components to avoid any adverse effect on the Develocity frontend. You should only enable background processing after being prompted by the Develocity support team.
Enabling the background processor will increase hardware resource requirements. It also increases required number of database connections when a user managed database is used (80 connections ✖️ background processor replica count). |
enterpriseBackgroundProcessor:
enabled: true
scaling:
replicas: 2
Appendix B: Example Helm Values File
You can download and verify the example Helm values file with the following commands:
$ curl -L -o example.values.yaml https://docs.gradle.com/enterprise/helm-standalone-installation/values-2024.2/gradle-enterprise-standalone-values-2024.2.yaml
$ curl -L -o example.values.yaml.sha256 https://docs.gradle.com/enterprise/helm-standalone-installation/values-2024.2/gradle-enterprise-standalone-values-2024.2.yaml.sha256
$ echo "$(cat example.values.yaml.sha256) example.values.yaml" | sha256sum -c
A direct download is available below:
Appendix C: Database Setup Scripts
-
gradle-enterprise-database-setup-zip-2024.2.zip (SHA-256 checksum)
-
gradle-enterprise-database-setup-zip-2024.1.zip (SHA-256 checksum)
-
gradle-enterprise-database-setup-zip-2023.4.zip (SHA-256 checksum)
-
gradle-enterprise-database-setup-zip-2023.3.zip (SHA-256 checksum)
-
gradle-enterprise-database-setup-zip-2023.2.zip (SHA-256 checksum)
-
gradle-enterprise-database-setup-zip-2023.1.zip (SHA-256 checksum)
-
gradle-enterprise-database-setup-zip-2022.4.zip (SHA-256 checksum)
-
gradle-enterprise-database-setup-zip-2022.3.zip (SHA-256 checksum)
Appendix D: Upgrading to Develocity 2024.2
If you are upgrading from a version < 2024.1 please ensure you have read the Upgrade Notes for 2024.1 as they include important migration steps for the Build Cache. |
The 2024.2 release provides significant updates to the Object Storage configuration. To migrate your configuration to the new version, follow one of the actions below.
AWS S3
s3
storage type deprecates some authentication attributes in objectStorage.s3.credentials
The list of deprecated keys is:
-
objectStorage.s3.credentials.secretName
-
objectStorage.s3.credentials.source
-
objectStorage.s3.credentials.accessKey
-
objectStorage.s3.credentials.secretKey
To replace those keys, you now can use one of the new credentials.type
values irsa
or keys
.
source: configuration
Before 2024.2:
objectStorage:
type: s3
s3:
bucket: example-bucket
region: example-aws-region-1
credentials:
source: configuration (1)
accessKey: "AKIA1234ABCD7890" (2)
secretKey: "dfml3s9rfdlsok390wledck30rkdfs" (2)
Since 2024.2:
objectStorage:
type: s3
s3:
bucket: example-bucket
region: example-aws-region-1
credentials:
type: keys (3)
keys:
accessKey: "AKIA1234ABCD7890" (2)
secretKey: "dfml3s9rfdlsok390wledck30rkdfs" (2)
1 | The source: configuration is deprecated and should be removed from the configuration. |
2 | The accessKey and secretKey keys should be moved under the keys . |
3 | The type key should be added with the value keys . |
secretName
Before 2024.2:
objectStorage:
type: s3
s3:
bucket: example-bucket
region: example-aws-region-1
credentials:
secretName: example-s3-credentials (1)
Since 2024.2:
objectStorage:
type: s3
s3:
bucket: example-bucket
region: example-aws-region-1
credentials:
type: keys (2)
keys:
secretName: example-s3-credentials (1)
1 | The secretName key should be moved under the keys . |
2 | The type key should be added with the value keys . |
The secret content does not change.
apiVersion: v1
kind: Secret
metadata:
name: example-s3-credentials
stringData:
accessKey: "AKIA1234ABCD7890"
secretKey: "dfml3s9rfdlsok390wledck30rkdfs"
source: environment
Before 2024.2:
objectStorage:
type: s3
s3:
bucket: example-bucket
region: example-aws-region-1
credentials:
source: "environment" (1)
Since 2024.2:
objectStorage:
type: s3
s3:
bucket: example-bucket
region: example-aws-region-1
credentials:
type: irsa (2)
irsa: (3)
serviceAccountAnnotations: (4)
ann1: foo
ann2: "bar.io/baz"
1 | The source: environment is deprecated and should be removed from the configuration. |
2 | The type key should be added with the value irsa . |
3 | irsa leverages "IAM Roles for Service Accounts" to authenticate the container |
4 | Additional annotation added to every component connected to S3 Object Storage |
Google Cloud Storage
objectStorage.type: googleCloud
is deprecated and planned to be removed in an upcoming release.
A new type, objectStorage.type: googleCloudStorage
, has been introduced as a replacement.
The new type supports a more secure authentication mechanism, such as WorkLoad Identity and Service Account.
source: configuration
Before 2024.2:
objectStorage:
type: googleCloud
googleCloud:
bucket: example-bucket
credentials:
source: configuration (1)
accessKey: "GOOG1234ABCD7890" (2)
secretKey: "dfml3s9rfdlsok390wledck30rkdfs" (2)
Since 2024.2:
objectStorage:
type: googleCloudStorage
googleCloudStorage:
bucket: example-bucket
credentials:
type: serviceAccount (3)
serviceAccount:
key: |
{
"type": "service_account",
"project_id": "PROJECT_ID",
"private_key_id": "KEY_ID",
"private_key": "-----BEGIN PRIVATE KEY-----\nPRIVATE_KEY\n-----END PRIVATE KEY-----\n",
"client_email": "SERVICE_ACCOUNT_EMAIL",
"client_id": "CLIENT_ID",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://accounts.google.com/o/oauth2/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL"
}
1 | The source: configuration is deprecated and should be removed from the configuration. |
2 | The accessKey and secretKey keys are no longer supported. It should be replaced with the serviceAccount key. |
3 | The type key should be added with the value serviceAccount and service account details should be provided |
secretName
Before 2024.2:
objectStorage:
type: googleCloud
googleCloud:
bucket: example-bucket
credentials:
secretName: example-gcs-credentials (1)
apiVersion: v1
kind: Secret
metadata:
name: example-gcs-credentials
stringData: (2)
accessKey: "GOOG1234ABCD7890"
secretKey: "dfml3s9rfdlsok390wledck30rkdfs"
1 | The secretName key should be moved under the serviceAccount . |
2 | The secret content should be changed from direct credentials to service account key. |
Since 2024.2:
objectStorage:
type: googleCloudStorage
googleCloudStorage:
bucket: example-bucket
credentials:
type: serviceAccount (1)
serviceAccount: (2)
secretName: example-gcs-credentials
apiVersion: v1
kind: Secret
metadata:
name: example-gcs-credentials
stringData: (3)
serviceAccountKey: |
{
"type": "service_account",
"project_id": "PROJECT_ID",
"private_key_id": "KEY_ID",
"private_key": "-----BEGIN PRIVATE KEY-----\nPRIVATE_KEY\n-----END PRIVATE KEY-----\n",
"client_email": "SERVICE_ACCOUNT_EMAIL",
"client_id": "CLIENT_ID",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://accounts.google.com/o/oauth2/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL"
}
1 | The type key should be added with the value serviceAccount . |
2 | The secretName key should be moved under the serviceAccount . |
3 | The secret content should be changed from direct credentials to service account key. |
Workload Identity Federation
You can provision credentials to Develocity dynamically using Workload Identity Federation.
Since 2024.2:
objectStorage:
type: googleCloudStorage
googleCloudStorage:
bucket: example-bucket
credentials:
type: workloadIdentity
Microsoft Azure Blob Storage
objectStorage.type: azure
is deprecated and planned to be removed in an upcoming release.
A new type objectStorage.type: azureBlobStorage
has been introduced as a replacement.
The new type supports a more secure authentication mechanism, such as WorkLoad Identity, and classic credentials with account name and key.
source: connectionString
Before 2024.2:
objectStorage:
type: azure (1)
azure:
container: example-container
credentials: (2)
source: connectionString
connectionString: "DefaultEndpointsProtocol=https;AccountName=exampleaccount;AccountKey=dfml3s9rfdl==;EndpointSuffix=core.windows.net"
Since 2024.2:
objectStorage:
type: azureBlobStorage (1)
azureBlobStorage:
container: example-container
credentials: (2)
type: accountInformation (3)
accountInformation: (4)
accountName: "example-account"
accountKey: "dfml3s9rfdlsok390wledck30rkdfs"
1 | The type: azure is deprecated and should be replaced with type: azureBlobStorage . |
2 | The source: connectionString is deprecated and should be replaced with type: accountInformation . |
3 | The type key should be added with the value accountInformation . |
4 | accountName and accountKey should be provided under the accountInformation |
secretName
Before 2024.2:
objectStorage:
type: azure
azure:
container: example-bucket
credentials:
secretName: example-azure-credentials (1)
apiVersion: v1
kind: Secret
metadata:
name: example-azure-credentials
stringData: (2)
connectionString: "DefaultEndpointsProtocol=https;AccountName=exampleaccount;AccountKey=dfml3s9rfdl==;EndpointSuffix=core.windows.net"
Since 2024.2:
objectStorage:
type: azureBlobStorage
azureBlobStorage:
container: example-bucket
credentials:
type: accountInformation (3)
accountInformation:
secretName: example-azure-credentials (1)
apiVersion: v1
kind: Secret
metadata:
name: example-azure-credentials
stringData: (2)
accountName: "example-account"
accountKey: "dfml3s9rfdlsok390wledck30rkdfs"
1 | The secretName key should be moved under the accountInformation . |
2 | The secret content should be changed from connectionString to accountName/accountKey. |
3 | The type key should be added with the value accountInformation . |
SAS & Workload Identity Federation
Before 2024.2:
objectStorage:
type: azure
azure:
container: example-container
credentials:
source: sas
sas: "dfml3s9rfdlsok390wledck30rkdfs"
endpoint: https://exampleaccount.blob.core.windows.net
Since 2024.2:
SAS is no longer supported. You can provision credentials to Develocity dynamically using Workload Identity Federation.
objectStorage:
type: azureBlobStorage
azureBlobStorage:
container: example-container
credentials:
type: workloadIdentity