I have the same issue with Gradle 3.3 and with a different task, deleting the output directory of the task (more concise: deleting the whole build directory, and the input-directory of the combineCssForMe task is inside the build directory) and rebuilding leaves the task as “UP-TO-DATE”.
WIth -i there is no information why it is UP-TO-DATE:
:appweb3-gui-web:combineCssForMe (Thread[Daemon worker Thread 22,5,main]) started.
Putting task artifact state for task ':appweb3-gui-web:combineCssForMe' into context took 0.0 secs.
:appweb3-gui-web:combineCssForMe (Thread[Daemon worker Thread 22,5,main]) completed. Took 0.0 secs.
I experienced this a lot, and there is really not really useful information as to why a task is UP-TO-DATE… in the case above, I end up with a runtime exception, because the CSS file is not part of the generated WAR, so this is really ugly. I rather have the task failed (because the input is not here but expected) than just silently ignoring it.
I would vote for more verbose output regarding to the various reasons why a task is UP-TO-DATE. Sometimes, with the -i command line options, the verbose is not bad and gives hints, e.g. like this:
gradlew -iPutting task artifact state for task ':mainproject:combinejsForMe' into context took 0.0 secs.
Skipping task ':mainproject:combinejsForMe' as it has no source files and no previous output files.
But this is not always the case, sometimes Gradle just “thinks” the task is up-to-date, and does not provide any information why it “thinks” this way.
I did some debugging for about 4 hours, and found out the issue with the above UP-TO-DATE message. But anyhow, I would like to propose some logging changes (LEVEL=DEBUG) for the class AbstractNamedFileSnapshotTaskStateChanges and method iterator(), because meaningful error messages really make sense and help to save time and effort of Gradle users. If the Gradle team is interested in this, I can contribute this, let me know.