codeconsole opened a new pull request, #16546: URL: https://github.com/apache/grails-core/pull/16546
## What `PropertyFileUtils` replaces the timestamp comment `Properties.store` writes with `# SOURCE_DATE_EPOCH = <value>`. When `SOURCE_DATE_EPOCH` is not set, that value was the start of the current UTC day. It is now `0`, the fixed epoch `SbomPlugin` already falls back to. ## Why These files end up in jars: `gsp/views.properties` is written by the GSP compiler, `META-INF/grails.build.info` by the `buildProperties` task. With a date that moves at midnight UTC, a plugin's jar changes once a day although nothing in it has, and every task with that jar on its classpath misses the build cache. Seen on CI in an application built from 16 GSP plugins: in a run whose only change was outside the Gradle build, all 24 module `compileGroovy` tasks came from the cache, but the application's `compileGroovy`, `compileGroovyPages`, `generateTagLibraryIndex` and `assetCompile` all ran again, because it was the first build of the UTC day. The only `assetCompile` cache hit among the runs checked followed another build on the same day. Setting `SOURCE_DATE_EPOCH` in CI works around it, but a build that does not set it should not lose its cache once a day. `SbomPlugin` falls back to the epoch for the same reason (a moving timestamp "changing the jar checksum and cascading cache misses through the compile classpath of downstream projects"). A set `SOURCE_DATE_EPOCH` is still used as given, so release builds are unchanged. ## Testing - `PropertyFileUtilsSpec`: the default is now `0` rather than today's date; all 6 tests pass. - `:grails-gradle-common:codeStyle` passes. -- 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]
