Short-circuit dependency chain if task outputs exist

Adding an outputs.upToDateWhen {} closure does not stop the normal input/output file checking. It simply gives you as a developer another chance to stop the task from being UP-TO-DATE. Returning true from this closure does not override the usual input/output file hash checking.

OK, that goes a long way toward explaining what I was seeing. Thank you for explaining this so clearly, without making me feel ignorant for making an honest mistake.

This may be a common mistake as well. I have come across similar questions from other Gradle users who could not get upToDateWhen to do what they wanted. I think they had the same misconception I did: they didn’t realize that upToDateWhen can only augment the standard checks, not replace them. Perhaps the upToDateWhen documentation should point out this limitation for the benefit of other Gradle users.

I get the feeling that you should only use a custom upToDateWhen {} closure and not use inputs.files This will mean that your custom logic is the only thing that’s considered in the UP-TO-DATE check.

Hmm, interesting option. I was already tweaking inputs.files for the consume task depending on whether the generated file already existed. I’m not sure whether you’re suggesting keeping my hack there or instead leaving inputs.files empty in the generate task. Either way, I see what you mean as an overall strategy: by leaving inputs.files empty I retain more complete control over the UP-TO-DATE check, whatever I want that logic to be. That is a useful way of looking at things. Nice.

I think I will keep my inputs.files (alreadyGenerated.exists() ? alreadyGenerated : generate) approach for now. It does the right thing, with no use of upToDateWhen. The more I think about it, the more I think it is an accurate reflection of the dependency semantics I want:

1. If the generated file already exists, then the file itself is the input to consume, and we don’t know or care how that file came to be.

2. But if the generated file does not already exist, then the file as produced by the generate task is the input to consume.

That’s a pretty straightforward interpretation of what inputs.files (alreadyGenerated.exists() ? alreadyGenerated : generate) is doing. Given my nonstandard requirements, that may be as elegant as I can expect things to be.

Thanks again for improving my mental model, @Lance! I expect it will be useful in the future too.