Laurence Gonsalves
04/03/2024, 5:48 PMTaskOutputs.cacheIf
and TaskOutputs.upToDateWhen
? Their descriptions from the docs seem to be using different words to say almost the same thing:
... Cache the results of the task only if the given spec is satisfied.cacheIf
What is the distinction between "cached" and "reused"? More concretely: If one has a task that looks at state that isn't in the file system — that is, the output of the depends on more than just the declared... Adds a predicate to determine whether previous outputs of this task can be reused.upToDateWhen
TaskInputs
and so seems non-deterministic if only the TaskInputs
are taken into account — then which is the correct one to use to ensure that Gradle knows that this task needs to be re-run if any tasks that depend on its output have been requested?Thomas Broyer
04/03/2024, 5:59 PMcacheIf
is specific to the build cache, so disabling caching could still reuse state local to your machine (in the build/
dir). upToDateWhen
is what determines if the task needs to re-run (when there is local or cached state that could be reused otherwise)
But you'll probably want to somehow declare that other source in TaskInputs
.Laurence Gonsalves
04/03/2024, 9:04 PMupToDateWhen{ false }
— output will never be reused
• cacheIf{ false }
— output may be reused (but if it is, it won't be via the build cache)
Is that right?Laurence Gonsalves
04/03/2024, 9:12 PMBut you'll probably want to somehow declare that other source inThe case I'm thinking about right now is a build tool that reads from a RDBMS. If the contents of that database have changed, then the tool's output will also change. In that kind of situation, I'm assuming the task should have.TaskInputs
upToDateWhen{ false }
, as there's no way for Gradle to see the contents of an RDBMS as an "input". Does that seem accurate?Laurence Gonsalves
04/03/2024, 9:14 PM