https://gradle.com/ logo
Join Slack
Powered by
I'm seeing some strange caching behavior in a Kotl...
# community-support
s
I'm seeing some strange caching behavior in a Kotlin 2.2.0 / JVM project with the application plugin applied: When I run 
./gradlew :cli:run --args="--version"
for the first time, I get output like
Copy code
> Task :cli:run
62.2.0

BUILD SUCCESSFUL in 47s
358 actionable tasks: 349 executed, 9 up-to-date
Configuration cache entry stored.
So the 
run
task is being executed. However, doing the same directly afterwards again, I get
Copy code
Parallel Configuration Cache is an incubating feature.
Reusing configuration cache.

BUILD SUCCESSFUL in 1s
349 actionable tasks: 349 up-to-date
Configuration cache entry reused.
So the 
run
task is not executed. I that's that's probably due to the build cache, but passing 
--no-build-cache
makes no difference. However, passing 
--no-configuration-cache
does make a difference, and I wonder why:
Copy code
❯ ./gradlew :cli:run --args="--version" --no-configuration-cache
Type-safe project accessors is an incubating feature.

> Configure project :
Building ORT version 62.2.0.

BUILD SUCCESSFUL in 4s
358 actionable tasks: 1 executed, 357 up-to-date
I though the configuration cache just caches how tasks are configured, but not their output. Does anyone have a clue what's going on here? IMO, the 
run
task should actually never be cached.
v
"does make a difference" where? Even in your last snippet I do not see the run task executed, just a lifecycle output from your build logic.
Can you show a build-scan?
If not, what does 
--info
(or if not enough 
--debug
) say about that run task?
And yes, the 
run
task by default should not be cacheable unless you configured it to be
s
Even in your last snippet I do not see the run task executed, just a lifecycle output from your build logic.
You're right, I myself confused
Copy code
> Configure project :
Building ORT version 62.2.0.
lifecycle output with
Copy code
> Task :cli:run
62.2.0
task output. Sorry, I've been staring at this for too long already...
v
Yeah, thought so 🙂
s
So, to correctly myself, neither 
--no-build-cache
nor 
--no-configuration-cache
makes the task run again.
v
My other questions stand 🙂
s
Working on it, just wanted to document the status 😉
👌 1
I've published a build scan for a smaller project which has the same problem when running `./gradlew clirun --args="--help" --scan`: https://gradle.com/s/bizkt2smrolyg is for the initial run which prints the help, https://gradle.com/s/ykp4vve3p4mi2 is for the second run which caches everything and does not print the help.
v
It is not cached, it is up-to-date
So you declared inputs and outputs for that task
If you do so and not configure it to be an untracked task, it will be up-to-date if neither inputs nor outputs change
s
So you declared inputs and outputs for that task
I don't think I did: https://github.com/sschuberth/stan/blob/main/cli/build.gradle.kts
v
Well, looking in the debugger, the 
:cli:run
task has 55 file inputs 32 property inputs and 1 file output. The inputs should be normal and if there were only inputs the task would not be up-to-dateable. But as there are inputs and outputs, it is. The output is 
stan/cli/build/native/agent-output/run
.
As there is "native" in the path, a wild guess would be that it is coming from the GraalVM plugin
👍 1
Yes, it is
org.graalvm.buildtools.gradle.NativeImagePlugin#configureAgent
adds a jvm argument provider that has an 
@OutputDirectory
property that is set to that directory
So I think if you add
Copy code
tasks.run.configure {
    doNotTrackState("The task is not supposed to be UP-TO-DATE.")
}
you should get the state you intend.
Or if the instrumentation by that GraalVM agent is not intended, you can set the 
tasksToInstrumentPredicate
on the 
agent
field of the 
graalvmNative
extension like
Copy code
graalvmNative {
    agent {
        tasksToInstrumentPredicate = Predicate { name != "run" }
    }
}
s
Thanks a lot for the sophisticated analysis! I'll give your proposals a try, and also I wonder whether this should be reported as a bug to the https://github.com/graalvm/native-build-tools folks...
v
I'm not so sure whether it is a bug. A 
run
task could well be up-to-date or even cacheable, for example if it processes some inputs to some outputs and rerunning would just produce the same result, it would be fully expected that the task is up-to-date and cacheable. If then the GraalVM adds an output to the task, the task should be out-of-date if it changed or vanished and also cache that output alongside if the task is cacheable. If it would not add the output to the task, that would actually be a bug and a more serious one.
s
if it processes some inputs to some outputs and rerunning would just produce the same result, it would be fully expected that the task is up-to-date and cacheable.
True, but that's something only the application itself can say, not a generic plugin that can be applied to any application, which could be interactive and do different things on each run based on user input (or similar environment changes).
Open in Slack
PreviousNext
Powered by