We have a large project that intermittently has issues with tasks being UP TO DATE, even though outputs were deleted, and inputs were changed.
In particular, we are currently having issues with “compileJava” reporting it’s UP TO DATE even though the source code has been changed. We later have a “compileDatabaseTestJava” task that fails because “compileJava” was not run, and classes/methods are missing in the .class files.
We previously had an issue with “copy” closures, where files were not being copied and the task was UP TO DATE. The closest we could get to reproducing the issue was adding a “delete” Action to the task, to insure the folder that was being using in task.outputs was empty.
We do have a fair amount of custom plugins and customization all over our build.gradle files, but since the issue is intermittent in nature, we’ve been unable to isolate it.
We’re currently planning to use “–debug”, and store all a list of all the inputs and outputs for tasks that are executed when using “gradle build”, but that seems like an inefficient way of trying to identify the problem.
What is the best way for us to go about troubleshooting this issue? Any ideas/tips/tricks?
At this point, I’m getting desperate enough that I’m resorting to trying to “hack” together to dump the contents of the *.bin files Gradle uses to store the task states, in order to get insight into why this is happening.