you can either use build scans or run with info lo...
# community-support
r
you can either use build scans or run with info logging (using -i) which usually logs why its not considered up to date. but be aware gradle logs a lot already with -i
đŸ§µ 2
m
What does it mean when it says
Class path of task ':sampleTask' has changed from d2552950096559ef63ae4e91a21d3a6d to c48d62e17e188ec99eedff9a64afb23f.
? I don't really know what the class path is in this case, especially since it changes when I simply re-run the task with no other changes.
r
what type of task is not up-to-date?
what type is :sampleTask?
ah nevermind.
if you change the build itself, the classpath usually changes
so you run the task, tweak the build and run the task again, the 2nd time its likely out of date as the tweaked build means the build classpath has changed
m
I don't change anything though
gradle :sampleTask && gradle :sampleTask
will run the task twice despite the fact that the second one should be up to date
r
gradlew
and
gradle
likely point to different binaries
the second invocation should be gradlew too
m
sorry both are the same binary, I mistyped ^^
either way, repeatedly clicking the "run" button in IDEA will always re-run it no matter what
Looks like it's caused by files in
.gradle
changing, since the project root is configured as workingDirectory on the task, but if I mark it as @Input instead of as @InputDirectory, it'll give an error saying it doesn't know how to interpret the file.
v
If it says the classpath changes, it is not the input directory property, but the classpath. You mentioned both CLI and IDE, but it is not fully clear. Does it happen with both or just when running from IDE? Could be that the IDE writes some init script that changes, are you on its latest version? But even if you get the classpath solved, of course having the whole project directory as input is usually making a task always out-of-date, but how to properly fix that is unclear without knowing what that task is doing exactly.