The GitHub Actions job "CI" on grails-core.git/fix/16711-gsp-compile-environment has failed. Run started by GitHub user jdaugherty (triggered by jdaugherty).
Head commit for run: 690a54545384ba1efbd4bc0a3377b09b7292c700 / James Daugherty <[email protected]> Compile views for a stated Grails environment, and key the build cache on it The forked compilers that compile GSP pages, JSON views and markup views ahead of time read application.yml and application.groovy for the environment they run in: CodeGenConfig merges that environment's block over the rest, and the page parser writes the codecs it reads there into the compiled page as constants. The environment was never stated to the compiler. It fell back to GRAILS_ENV, inherited from the Gradle daemon and so from the shell, and to development where that was not set; -Dgrails.env given to Gradle never reached it. The compile tasks have been cacheable since 8a3cf63ae2 with no input for the environment, so two clean builds that differed only in GRAILS_ENV shared a cache entry, and a production build could be handed pages compiled with development's codecs. The tasks now carry the environment as grailsEnvironment and pass it to the compiler as the grails.env system property, so nothing the compiler inherits decides. It defaults to the environment the build runs with - a -Dgrails.env the build already gave the compiler among the fork options, else the grails.env system property given to Gradle, else GRAILS_ENV, each read for a blank before the next is consulted, as the application's own resolution reads them - and to production where none is set, which is what the archive the views are packaged into is built for, and what grails.build.info already records. The fork argument is read as the default and withheld from the compiler, which gets the input: the environment's full name, read as the application reads the name it is started with, which is also what the cache key holds. A blank input fails the build before anything is compiled or removed. A build that set GSP codecs only under environments.development used to ship them in its archive; it now gets the production configuration there, as the running application does. An environment change has to reach every page. The page compiler leaves a page alone whose class in the destination is newer than its source, and leaves the class of a page that is gone, so a production build after a development one would keep development's pages and store them in the cache under production's key. Each compile task now empties its destination, with Gradle's deleter, before it compiles, at the cost of compiling every view each time it runs; the destination holds exactly what the execution compiled, which is what the cache keeps under its key, and so has to be a directory of the task's own within the build directory and off the compiler's classpath, which a build that points it elsewhere is told. The environment is read once, so that what is compiled is what is keyed. The page compile task's source directory is internal rather than an input directory, which has to exist where the directory need not, and every page beneath it is an input in its place, filters notwithstanding, since the compiler finds the pages by the directory and compiles them all. Fixes #16711 Report URL: https://github.com/apache/grails-core/actions/runs/39670967979 With regards, GitHub Actions via GitBox
