jamesfredley commented on code in PR #16528:
URL: https://github.com/apache/grails-core/pull/16528#discussion_r4210587048
##########
grails-gradle/plugins/src/main/groovy/org/grails/gradle/plugin/core/GrailsGradlePlugin.groovy:
##########
@@ -1343,24 +1341,14 @@ ${importStatements}
def extraProperties =
project.extensions.getByType(ExtraPropertiesExtension)
def overriddenMainClass = propertyMainClassName ?:
springBootMainClassName
if (!overriddenMainClass) {
- // the findMainClass task needs to set these values
- extraProperties.set('mainClassName', project.provider {
- File cacheFile =
findMainClassTask.get().mainClassCacheFile.orNull?.asFile
- if (!cacheFile?.exists()) {
- return null
- }
-
- cacheFile?.text
- })
-
- springBootExtension.mainClass.set(project.provider {
- File cacheFile =
findMainClassTask.get().mainClassCacheFile.orNull?.asFile
- if (!cacheFile?.exists()) {
- return null
- }
-
- cacheFile?.text
- })
+ // the findMainClass task finds the value. A task-output
provider would fail anything reading it
+ // while the build is configured, and a project.provider
would keep the value the file held
+ // when the configuration cache entry was stored, so both
read it through a value source
+ Provider<String> foundMainClass =
project.providers.of(FoundMainClassValueSource) {
Review Comment:
This value source backs both `springBoot.mainClass` and `mainClassName`.
Gradle calls `obtain()` once for that provider. If a build reads either
property during configuration, including a clean checkout where the cache file
does not exist yet, the result (null) is memoized. A task that later reads the
provider after `findMainClass` still gets null. `bootJar` does not show this
because it uses the separate task-output provider.
Keep execution-time reads on the `findMainClass` output. Please add a test
that reads `springBoot.mainClass` during configuration and then reads both
public providers after `findMainClass`, on a clean checkout and after the
application class changes.
##########
build-logic/plugins/src/test/groovy/org/apache/grails/buildsrc/TestTaskShardingPluginSpec.groovy:
##########
@@ -225,15 +265,15 @@ class TestTaskShardingPluginSpec extends Specification {
private BuildResult run(String... arguments) {
GradleRunner.create()
.withProjectDir(testProjectDir.toFile())
- .withArguments(arguments + ['--stacktrace'])
+ .withArguments(arguments + ['--stacktrace',
'--configuration-cache', '--configuration-cache-problems=fail'])
Review Comment:
These runs pass `--configuration-cache`. `TestTaskShardingPlugin` prints
`TEST_SHARD_MANIFEST` only from `taskGraph.whenReady`, and that callback is not
replayed when a cached configuration is reused. The determinism case runs
`testShard` again with the same shard count and index, so `shardPaths()` fails
its `manifest != null` assertion.
Emit the manifest from an execution-time action using values captured during
configuration, and rerun the affected build-logic tests with the cache.
--
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]
