Gradle Enterprise 2018.3

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 application, previously only available as a Docker image is now also available as an executable JAR. This may be a more compelling deployment format for environments that are less accommodating of Docker.

See the new build cache node user manual for more information.

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.