Add gradle property to enable task execution logging

[eriwen]

In 4.0, we want to only log "interesting" stuff and no longer include executed tasks by default.

Let us add a property to turn that back on, org.gradle.logging.tasks=true perhaps.

Expected Behavior

./gradlew baz -Dorg.gradle.logging.tasks=true
:fooTask UP-TO-DATE
Log messages here
:barSpec
:baz

BUILD SUCCESSFUL in 1s

Default Behavior

./gradlew baz -Dorg.gradle.logging.tasks=false
[:fooTask]
Log messages here

BUILD SUCCESSFUL in 1s

Context

[adammurdoch]

What's the use case?

[eriwen]

Sorry for the thin issue here. The use case is: I really want to see the all tasks that are executed by my gradle build just like Gradle 3.x.

I've gone ahead and expanded the description to make this more concrete.

[big-guy]

Is this already affected by --console=plain?

[oehme]

I thought what we would do is switch from lifecycle to warning as the default level. Then we'd just need a switch to go back to lifecycle logging instead of a specific switch that only affects tasks.

[eriwen]

@oehme I like the idea, but I fear the number of changes required to get everything we and others want displayed at the WARN level. To reduce risk, I think we might want to allow setting the logging level from Gradle properties so that users can default to LIFECYCLE level.

I like the idea a lot. It's would almost be considered a "light" debugging level. Hmm.

[adammurdoch]

Why would you not use an existing way to explore what happens during a build, such as the various IDE integrations, a build scan, or the profile report?

I think less is more when it comes to adding command-line flags (which is what the title says to me). There should be a very strong benefit to justify a new flag.

[eriwen]

I agree we should not implement a special flag here. I really like the idea of defaulting to WARN level. When I use this myself, logs magically become much more useful.

[eriwen]

Closing as rejected