jdaugherty opened a new pull request, #16528: URL: https://github.com/apache/grails-core/pull/16528
Makes the Grails builds, and the applications and plugins Grails generates, work with the [Gradle configuration cache](https://docs.gradle.org/current/userguide/configuration_cache.html). The root, `build-logic`, `grails-gradle`, `grails-forge` and `end-to-end` builds now run with `org.gradle.configuration-cache=true`, and so do applications and plugins created by Forge and the base profile. ## Prerequisites This is a draft until these are merged and their snapshots are published. `dependencies.gradle` already points at the asset-pipeline and grails-publish snapshots, so until then CI cannot resolve the build. - apache/grails-gradle-publish#43: makes publishing compatible with the configuration cache (`grails-publish-plugin` 1.0.0-SNAPSHOT) - wondrify/asset-pipeline#494: makes the asset-pipeline Gradle plugin compatible with the configuration cache (`asset-pipeline-gradle` / `asset-pipeline-bom` 5.2.1-SNAPSHOT) - skillsjars/skillsjars-gradle-plugin#19: makes the SkillsJars plugin compatible with the configuration cache. Until a release with it ships, the guide and the `end-to-end` builds mark `extractSkillsJars` as not compatible, so those builds run without the cache instead of failing. ## Changes **Build logic** - `PublishPlugin`, `GroovydocEnhancerPlugin`, `SbomPlugin` and `GrailsCodeStylePlugin` no longer reach the project, script properties or closure owners while tasks run. - The BOM builds compute their POM property names while they are configured. The generated POMs and the constraint documentation are byte-identical to before. - The Asciidoctor Gradle plugin cannot be stored in the configuration cache, so the guides are now rendered by `ConvertAsciidocTask`, which runs AsciidoctorJ in a worker. The output is unchanged. - The shared test, functional test, TCK, publish and RAT scripts use injected services and providers instead of the project while tasks run. **Vulnerability scan** - The archived Sonatype `scan-gradle-plugin` cannot be stored in the configuration cache. It is replaced by our own `vulnerabilityScan` task in `build-logic/vulnerability-scan`. - The task looks up the resolved `runtimeClasspath` and `compileClasspath` in OSV and, when `SONATYPE_GUIDE_USERNAME` and `SONATYPE_GUIDE_TOKEN` are set, in Sonatype Guide. A vulnerability found in both is reported once. - The credentials are read only when the scan runs, so they are never stored in the configuration cache. - Both sources' answers are cached for an hour in the Gradle user home (`vulnerabilityScan.cacheTtl`), because Sonatype Guide lookups cost credits. - Exclusions name a vulnerability ID or alias plus a `group:artifact`, so a version bump no longer orphans them. Each exclusion needs a reason. - `vulnerabilityScanReport` writes the Markdown summary used by the workflow. The workflow no longer uses `pull_request_target`: a pull request from a fork gets no secrets, so it is scanned against OSV only, and the summary says so. **Grails Gradle plugins** - The `bootJar`/`bootWar` main class now comes from the output of `findMainClass`. Previously it came from a provider evaluated when the entry was stored, so it was empty in a build that reused the cache. - The CLI companion probe looks only at projects of the current build, so it no longer invalidates the entry. - Every TestKit build runs with the configuration cache and fails on any problem. **Forge** - Generated `gradle.properties` files enable the configuration cache. - The nohttp Checkstyle task and `RockerTask` no longer use the project while they run. - The generated Asciidoctor build marks its tasks as not compatible. **Documentation** - A new "Using the Gradle Configuration Cache" section in the Gradle build chapter. - A What's New entry and upgrade note 85. - Updates to the `gradle-developer` and `grails-8-upgrade` skills. ## Performance Every Gradle invocation of the root build first configures all of its projects, a fixed cost of about 9 s (16 s to plan a full `build`). When the same tasks run again, a reused configuration cache entry replaces that with about 1 s. The saving is in seconds per invocation, so it matters most for short, repeated commands. Measured on this branch with a warm daemon, median of 3 runs: Apple M4 Max (16 cores), Gradle 9.8.0, JDK 21, the repository's `-Xmx3G`. | Command | Without the configuration cache | Entry reused | Saved | | --- | --- | --- | --- | | `./gradlew :grails-core:test --tests grails.util.GrailsStringUtilsSpec --rerun` (rerun one spec) | 12.7 s | 3.3 s | 9.5 s | | `./gradlew :grails-core:compileGroovy` (up to date) | 9.7 s | 1.1 s | 8.6 s | | `./gradlew help` (configuration only) | 9.1 s | 1.1 s | 8.0 s | | `./gradlew build --dry-run` (plans the whole build) | 16.5 s | 1.5 s | 15.0 s | A long build saves the same few seconds. A run of a module's whole test suite or a full `build` takes minutes, so the saving there is a small fraction. A fresh CI job has no entry to reuse, so CI time is not expected to change noticeably; that was not measured. ## Verification - Dry runs that store a configuration-cache entry across the main CI lanes found no problems. Root build: `build`, `check`, publishing, the guide, style and analysis aggregation, dependency/BOM validation, JaCoCo, `vulnerabilityScan`, `rat`. Also `grails-gradle` and `grails-forge` builds and code style. - A second identical run reuses the stored entry. - An earlier full run of the test suites with the configuration cache on (on 8.0.x) executed 23,389 tests. The only failure was a known flaky `gorm.BookSpec`, which passed on rerun. - grails-gradle plugin tests (all TestKit builds with the configuration cache), the Forge specs, the `end-to-end` build, and the 21 vulnerability-scan specs pass. - `codeStyle`, `validateRepositoryConventions` and `rat` pass. - The new scanner was run against the live OSV and Sonatype Guide APIs across the root build: 167 projects took 43 s while storing the entry, and about 1 s on reuse. The scan currently fails on findings that have fixed releases: jackson 2.22.3 / 3.1.7, Tomcat 11.0.25, guava 33.7.2 and hibernate-core 7.4.9. Those bumps belong in a separate change to `dependencies.gradle`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
