What is the difference between `TaskOutputs.cacheI...
# community-support
l
What is the difference between
TaskOutputs.cacheIf
and
TaskOutputs.upToDateWhen
? Their descriptions from the docs seem to be using different words to say almost the same thing:
cacheIf
... Cache the results of the task only if the given spec is satisfied.
upToDateWhen
... Adds a predicate to determine whether previous outputs of this task can be reused.
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
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?
t
cacheIf
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
.
l
Thanks. To make sure I understand: •
upToDateWhen{ 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?
But you'll probably want to somehow declare that other source in
TaskInputs
.
The 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
upToDateWhen{ false }
, as there's no way for Gradle to see the contents of an RDBMS as an "input". Does that seem accurate?
(FWIW, in my own projects I have a way to determine if the DB will have changed based on file system contents, but I'm thinking about the case where some users of a plugin cannot do this for whatever reason.)