Next Workshop: Maven Build Cache Deep Dive – June 9th (9am – 12pm PDT). Learn more and register here.
Gradle Enterprise 2022.1
Gradle Enterprise 2022.1 introduces a new REST-style API, leveraging the OpenAPI standard, that makes extracting build data much easier than before and offers a new installation and deployment process that leverages more conventional Kubernetes tooling for cluster deployment and also simplifies single-host deployments.
Read on for more details of these and other new features.
Use version 1.13.1 of the Gradle Enterprise Maven extension, version 3.9 of the Gradle Enterprise Gradle plugin, version 2.2.3 of the Gradle Enterprise Test Distribution Gradle plugin, version 1.6.8 of the Gradle Enterprise Test Distribution Agent, and version 12.1 of the Gradle Enterprise Build Cache Node for optimal usage of Gradle Enterprise.
The new Gradle Enterprise API is a new foundation for interacting with Gradle Enterprise programmatically. It follows a REST-style and uses the OpenAPI standard to provide a formal specification. Tooling exists for most popular programming languages that can be used to generate data models and client code.
More resources and operations will be added over time, particularly resources that describe particular aspects of builds in an easy-to-process data model.
In this release, you can use the API to discover historical builds, be notified of new builds, extract basic build attributes from Gradle and Maven builds (e.g. build duration, project name, user, hostname, tags), and extract key build caching performance metrics (e.g. cache hit ratio, estimated time savings). See the samples project for a quickstart example that can be used as the basis of exporting build cache performance metrics from Gradle Enterprise to another system, such as a dedicated data warehouse or other analysis tooling. You can also use it to programmatically register and configure build cache nodes. For more information, including the API specification, please see the new Gradle Enterprise API manual.
The existing “Gradle Enterprise Export API” is still available and will be supported for some time. Currently, it provides some functionality, namely the ability to observe the raw low-level events of a build, that is not available via the new API. As this functionality later becomes available via the new API, the Export API will be deprecated and eventually sunset. At that time, migration guides and assistance will be available. If you have any questions or concerns about your Export API usage, please contact Gradle Enterprise support.
Gradle Enterprise began offering targeted support for deploying to Kubernetes in 2018. Since then, Kubernetes tooling and practices have matured significantly, with Helm emerging as a convention for installing and configuring applications. In order to make installation and upgrade easier, Gradle Enterprise now embraces Helm as the preferred mechanism for installation.
This change also affects users currently installing standalone directly to a single-host as the existing Replicated-based installation process is being phased out, to be replaced by an easier-to-use and more reliable Helm-based process that leverages k3s – an industry-leading Kubernetes distribution suitable for single-host usage – that does not require Kubernetes expertise.
❯ helm search repo gradle NAME CHART VERSION APP VERSION DESCRIPTION gradle/gradle-enterprise 2022.1.0 2022.1 Official Gradle Enterprise Chart gradle/gradle-enterprise-standalone 2022.1.0 2022.1 Official Gradle Enterprise Chart
The existing Replicated-based installation process for both single-host and Kubernetes is now deprecated, and will no longer be supported as of January 2023. New releases up to and including Gradle Enterprise 2022.3, including its patch releases, will be installable via the deprecated process and the new Helm-based process. Subsequent versions will only be installable via the Helm-based process.
New guides are available for installing as a standalone application on a single host, or into an existing Kubernetes cluster using the Helm-based process, along with a migration guide. If you have any questions or concerns about migrating or require assistance in planning a migration, please contact Gradle Enterprise support.
It is now possible to inform build cache nodes that they are using a dedicated storage volume of a certain size as part of the deployment configuration, removing the need to synchronize the cache size setting within the application with what is specified as part of the deployment configuration. This is particularly useful when deploying to Kubernetes environments where a persistent volume must be allocated with a fixed size and is intended to be used exclusively by the build cache node.
--use-exclusive-volume-with-size=«size» argument or
EXCLUSIVE_VOLUME_SIZE=«size» environment variable can be used to enable this operational mode. The size value is expected to be in the Kubernetes resource quantity format, which is typically how volume sizes are expressed in Kubernetes manifests.
When set, the build cache will be automatically configured to use all of the specified space with any previous size settings being ignored and configuration of the size via the user interface being disallowed.
When deploying to Kubernetes, the built-in build cache node provided with Gradle Enterprise will be automatically configured with this option and with the size specified at install time.
Temporarily degraded performance due to data reindexing
Upon upgrading, a data reindexing process will be initiated in the background with Gradle Enterprise being usable for its duration. CPU usage will be increased and performance may be slightly degraded. For large installations storing many build scans, the reindexing process may take several hours. During this time, some builds may be omitted from cross-build data visualizations. Recent builds are prioritized, making their data available sooner.
- [FIX] - Helm-based install process fails when no config values are provided
- [FIX] - Build scan lists may display error page for large installations
- [FIX] - Obtaining support bundle from Helm-based install requires obscure credential
- [FIX] - Updating database configuration using Helm-based install process does not automatically restart affected pods
- [FIX] - SAML-based login when using end-to-end plain HTTP causes infinite redirect loop
- [NEW] - REST-style API for extracting build data and automating Gradle Enterprise
- [NEW] - Simpler and more Kubernetes-friendly installation and operation
- [NEW] - Simpler build cache node management when using dedicated data volumes
- [NEW] - File paths within the user home directory are shown as relative paths
- [NEW] - System architecture is displayed in Gradle and Maven build scans
- [NEW] - The effective value of ‘rerunGoals’ is displayed in Maven build scans
- [NEW] - The ‘allowInsecureProtocol’ and ‘useExpectContinue’ build cache settings are displayed in Maven build scans
- [FIX] - Gradle dependency comparison displays incorrect entries when a dependency variant name was changed
- [FIX] - Gradle builds containing Kotlin script build cache operations are not displayed under certain conditions
- [FIX] - Console log page is not displayed when there is no output, under certain conditions