How to show all potentially-executable tasks during a build as older Gradle used to to?


(Renato Athaydes) #1

Gradle used to show which tasks participated in a execution.
For example, typing ./gradlew test would show this:

:compileJava NO-SOURCE
:compileGroovy UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileTestJava NO-SOURCE
:compileTestGroovy UP-TO-DATE
:processTestResources NO-SOURCE
:testClasses UP-TO-DATE
:test UP-TO-DATE

But with new Gradle versions (at least 4.2) we see only:

BUILD SUCCESSFUL in 19s
11 actionable tasks: 9 executed, 2 up-to-date

That’s definitely not an improvement. Why would I NOT want to see the tasks that Gradle thought should have been executed (even if skipped)?

Anyway, is there a way to revert to the previou behaviour?


(Stefan Oehme) #2

The question is why you would want to see it. In day-to-day use you can trust Gradle that it will execute exactly what was needed for what you asked for. If you say gradle test, Gradle will run everything necessary to execute your tests.

The only time that I can come up with where you really care about seeing what tasks get executed in detail is if you are debugging an issue or adding some new task and making sure it is in fact executed. For that case you can use either --scan or --profile or the new --console=verbose mode we’ll add in 4.3.


(Renato Athaydes) #3

That’s not how I see it. It’s absolutely not clear when I run a task, which tasks will be attempted to run.
This is very basic information that I am very interested in.
Hiding the most basic information of a build (which tasks were considered for execution and which ones did run) does not improve understanding of a build.

I trust Gradle to know that but I don’t trust myself to know that without help.


(Renato Athaydes) #4

To substantiate my argument a little bit more, here’s a very common example of how showing which tasks get to run can help.

I change a file in a source that I assume is included in sources, say src/main/resources/blah.txt. I expect the tests to run again, but for some reason, this directory is excluded from sources and the tests don’t even run.

If I saw that the test task didn’t even run, I wouldn’t assume my change had worked. This could cost a lot of time to fix later, specially for junior developers that do not have full understanding of a build (but even experienced people cannot understand all aspects of large builds).

You decided to hide this crucial information to save a few lines of output. Those few lines of output didn’t cost anything. They were useful. Hiding them does not improve anything at all.

End of rant!

Will try the options you suggested…