The GitHub Actions job "SiteMesh 2 Compatibility" on grails-core.git/feat/add-configuration-cache-support has failed. Run started by GitHub user jdaugherty (triggered by jdaugherty).
Head commit for run: 2cfc69e22bf0e170292ef63c742776fc76a3ef1a / James Daugherty <[email protected]> Make the builds and Grails applications compatible with the configuration cache The root, build-logic, grails-gradle, grails-forge and end-to-end builds now run with the Gradle configuration cache, and so do the applications and plugins Grails generates: Forge and the base profile skeleton set org.gradle.configuration-cache=true in their gradle.properties. Build logic - PublishPlugin, GroovydocEnhancerPlugin, SbomPlugin and GrailsCodeStylePlugin no longer reach the project, script properties or closure owners while tasks run; the published artifact list, groovydoc properties and SBOM inputs come from providers and task parameters. - The BOM builds compute their POM property names while they are configured. The generated POMs and constraint documentation are unchanged. - The asciidoctor Gradle plugin, which cannot be stored, is replaced by ConvertAsciidocTask, which runs AsciidoctorJ in a worker; the guides render the same output. - FetchTagsTask and ExtractDependenciesTask take their inputs as properties. - The shared test, functional test, TCK, publish and RAT scripts use injected services and providers instead of the project at execution time. Vulnerability scan - The archived Sonatype scan-gradle-plugin, which cannot be stored, is replaced by our own vulnerabilityScan task. It looks the resolved runtimeClasspath and compileClasspath up in OSV and, when SONATYPE_GUIDE_USERNAME and SONATYPE_GUIDE_TOKEN are set, in Sonatype Guide, reporting a vulnerability both know of once. The credentials are read when the scan runs, so they never become part of the configuration cache. The answers of both are cached for an hour in the Gradle user home (vulnerabilityScan.cacheTtl), since Sonatype Guide lookups cost credits. - Exclusions name a vulnerability id or alias and a group:artifact, so a version bump no longer orphans them; each needs a reason. - The root vulnerabilityScanReport task summarizes every project in Markdown for the workflow, which no longer needs pull_request_target: a fork pull request is scanned against OSV only, and the summary says so. Grails Gradle plugins - The bootJar and bootWar main class is derived from the output of findMainClass instead of a provider evaluated when the entry is stored, so it is no longer empty in a build reusing the cache. - The CLI companion probe only looks at projects of the current build, which no longer invalidates the entry. - Every TestKit build runs with the configuration cache and fails on any problem; the fixtures were updated for it. Forge - The generated gradle.properties enables the configuration cache, the nohttp Checkstyle task and RockerTask no longer use the project while they run, and the generated asciidoctor build opts its tasks out. The build points at the asset-pipeline 5.2.1-SNAPSHOT and grails-publish 1.0.0-SNAPSHOT plugins, whose configuration cache fixes are pending in their own repositories. The SkillsJars extraction stays marked as not compatible until a release of the plugin with the fix is available. Documentation: a new Configuration Cache section in the Gradle build chapter, a What's New entry and upgrade note for Grails 8.1, and the gradle-developer and grails-8-upgrade skills. Report URL: https://github.com/apache/grails-core/actions/runs/37360057709 With regards, GitHub Actions via GitBox
