How do you make the most of the Build Cache? Register for our live webinar on February 28th.
Gradle Enterprise 2018.3
The buildSrc component of builds (the embedded build used to compile and package custom build logic) is now comprehensively represented in build scans. This includes configuration and task execution profiling, build cache effectiveness, dependency resolution, and all other areas of insights provided by build scans. The buildSrc component is built for each invocation of Gradle, making it critical that it builds as quickly as possible. Build scans now make it much easier to optimize and debug this part of your builds.
The remote build cache node application, used to create a multi-node distributed build cache, can now be deployed as an executable JAR in addition to the existing Docker container image. This makes it easier to operate a node in environments that are not accommodating of Docker. Additionally, the node can now be fully configured by configuration file, making it easier to completely automate the deployment and operation of one or more nodes.
Read on for the details of these and other new features and improvements.
Gradle’s buildSrc convention makes it easy to use custom logic in your build, by automatically building any project named “buildSrc” in the root of your project and making its code available to the rest of the build logic. This is effectively a build within a build. Previously, build scans conveyed how long it took to build buildSrc, but its workings were opaque. Now, the buildSrc build is considered in all of the existing build scan insights.
The performance overview now breaks down the build time of the buildSrc build into its different components:
The configuration performance view now includes the scripts and plugins applied during the buildSrc build:
The task execution performance view now includes the tasks executed in the buildSrc build:
The timeline now shows the entire duration of the build and includes the buildSrc tasks:
The build scan comparison views now include relevant aspects of the buildSrc build:
All other build scan areas and functions such as plugins, project structure, test results, dependencies, and the performance dashboard now also include buildSrc information.
The configuration performance view now indicates the time taken to execute registered listeners of lifecycle events such as “afterEvaluate” and “projectsEvaluated”. This makes it easier to diagnose the cause of slow configuration time being slow listeners of these events.
Task configuration avoidance, coming in Gradle 4.9, is a mechanism for reducing configuration time by doing less work creating and configuring tasks that are not needed for executing a build. The configuration performance view now breaks down how effective this was for a build, and indicates which scripts and plugins created and configured tasks eagerly. This can be used to identify and prioritize build logic to be migrated to the new task configuration avoidance APIs, in order to reduce build configuration time.
See Gradle’s documentation for more information on task configuration avoidance.
The build cache node can now be completely configured via a single YAML configuration file, in addition to the existing UI. This makes it easier to automate the deployment of a cache node, as this configuration file can be generated by deployment automation.
See the new build cache node user manual for more information.
Gradle Enterprise can now be easily deployed to an existing Kubernetes cluster, which is a compelling deployment option if your organization operates such a cluster.
The installation process and operational procedures are naturally different when deploying in this fashion. For more details, please see the dedicated admin manual for deploying to Kubernetes.
Database version upgrade
This release includes a major version update to the internal database used by Gradle Enterprise. Gradle Enterprise may take a few extra seconds to start in order to perform this update, after updating.
Performance dashboard index rebuild
After upgrading, the performance dashboard may be unavailable for a few minutes while indexes are rebuilt in order to include buildSrc information in the performance dashboard.
- [FIX] Allow use of untrusted SSL certs with build cache nodes
- [FIX] Failure section may indicate wrong failure number in header
- [FIX] Viewing plugins section of build with init or settings scripts plugin causes error
- [FIX] Tasks from buildSrc do not provide output origin task links
- [FIX] Timeline crashes when more tasks than configured maxWorkers are executed in parallel
- [FIX] Console log crashes under some circumstances when displaying failures
- [FIX] Application attempts to reprocess deleted builds
- [FEATURE] buildSrc insights
- [FEATURE] Task configuration avoidance insights
- [FEATURE] afterEvaluate and other configuration lifecycle callback insights
- [FEATURE] Build cache node executable JAR deployment
- [FEATURE] Automated build cache node deployment
- [FEATURE] Kubernetes deployment support
- [FIX] Database indexes may not be used under specific circumstances
- [FIX] Export API may return inconsistent results for deleted scans
- [FIX] Performance dashboard displays stale data
- [FIX] Performance dashboard hangs when data is being loaded
- [FIX] Tab order in scan list page is not consistent
- [FIX] Console log links are not consistent with the rest of the application links
- [FIX] Task name tooltip overflows in case of long list of tasks
- [FIX] Pinning a build is slow
- [FIX] Dependency configuration erroneously shows project dependencies in some cases
- [FIX] Dependency comparison erroneously shows project dependencies in some cases
- [FIX] Red stripes for negative time values in performance dashboard not showing in FireFox
- [FIX] Composite builds show incorrect root project name