Introduce tasks report that renders task dependencies as tree

[bmuschko]

As a user, I want to know all the tasks that are available, but instead of a flat list, I want to know how they depend on one another. Even better: tell me why.

Expected Behavior

I propose perhaps a flag for the gradle tasks command like --tree or --dependencies that prints the report suggested above. I strongly feel that this ought to be baked in.

A user can render tasks and their task dependencies as a tree. It would be helpful to have a filter option that allows for rendering task dependencies for just a single task or a collection of tasks. The new report will likely expose poor performance for large projects if all tasks are rendered at once as the whole task graph needs to be walked.

Current Behavior

The existing tasks report does not render task dependencies at all.

Context

This a very popular plugin https://github.com/dorongold/gradle-task-tree, and we've gotten a lot of feedback from folks that suggest this should be built-in

The end user can discover task dependencies and make an educated decision on whether to run a task or not.

[Reager-]

Would be great also to integrate this with the build scan tool when using -Dscan and visualize the tree with something like this http://bl.ocks.org/d3noob/8375092

[marvertin]

It is very missing.

[ldaley]

Would be great also to integrate this with the build scan too

This is something that is on our radar for build scans.

[lptr]

Instead of a task hierarchy, what I usually find asking is "why did task X get triggered when I asked for task Y". In a project where there are lots of tasks, it might be more useful to address this use case instead of printing a huge tree.

[kno10]

Yes, when debugging unnecessary task executions (to speed up incremental build), what you really are interested in is "why does gradle think we need to rerun this task". The task tree is useful for this, but still requires manually checking which of the prerequisites get executed.

For those struggling with the same problem: --debug is helpful. In my case, it contained the message

Task ':X:javadoc' is not up-to-date because:
  Value of input property 'options.footer' has changed for task ':X:javadoc'

because the footer was set to contain the build time... the solution then was to add to javadoc {}:

inputs.property("options.footer","") // Ignore

to not use the footer for change detection, and afterwards it would stop being rebuilt every time. It will still use the other mechanisms - so a change to a java file should cause the javadoc to be rebuilt.

As you can see in this example, it is not always a task that is causing a rebuild. Any time (or commit) dependent option can be causing extra rebuilds, and logging with --debug is likely the way to go for debugging this.

[simtel12]

I think that the original request is still valid.

We have a scenario where built artifacts get stored after a CI build. They're then pulled out of a number of other jobs that want to run tests with those artifacts (androidTest suites). We want to run a subset of those test suites without having to re-run the entire task hierarchy - because the intermediates were not stored, and so the build will be considered "out of date".

At the moment there is no good [built-in] way to discover the dependencies of the test task.

[gavenkoa]

--dry-run (or short -m) is the only way to debug task dependencies.

[IARI]

Are there any plans/updates regarding this?

[sky-ruimartins]

Long standing required feature.

[BenderRodrigez]

When you are working in a large project with multiple sub-projects and sometimes not very clean dependencies, it is really devastating to not have any tool to determine and cleanup tasks execution tree. --dry-run does not provide any valuable information about references, only the set of tasks to execute.

Thank you for the link to plugin!

[sschuberth]

Another plugin I can recommend until this is implemented upstream is https://gitlab.com/barfuin/gradle-taskinfo.