The GitHub Actions job "Groovy Snapshot Canary Build" on grails-core.git/test/compiler-config-runtime-classpath-producer has succeeded. Run started by GitHub user matrei (triggered by codeconsole).
Head commit for run: 9cde802ef7f9aff0bc4d65fc2872e294f38e9911 / Mattias Reichel <[email protected]> test: pin that the compiler config generator stays off the runtime classpath The task-based wiring that 9a529d1996 replaced with a doFirst declared runtimeClasspath as an input of the generator task, so any task whose output reached the runtime classpath became a transitive dependency of compileGroovy. A post-compile step that feeds the runtime classpath, such as asset-pipeline output or the exploded plugin directory, then closed a cycle. That is the concern raised on #16114. The generator introduced there takes its script from grails { } state and declares no classpath input, so that edge no longer exists. This test recreates the scenario: a task that runs after classes and puts its output on the runtime classpath via runtimeOnly files(task). It asserts the generator does not depend on that task, and that compileGroovy and the producer schedule together without a cycle. Report URL: https://github.com/apache/grails-core/actions/runs/34266396110 With regards, GitHub Actions via GitBox
