I’m trying to enumerate all tasks (as ‘gradle tasks --all’ does). I’ve noticed a few things. It does not matter if I use the root project’s task container or gradle’s task graph container, I only get the tasks needed to build my task, and not all tasks. So, a solution would be to make my task depend on all the tasks available in all projects. Is there a way to do this? I would do the traversal myself, but I’m not aware of any “god anchor-task” for each project on which I could depend that would cause gradle to build up the graph for each project.
You’ll need to recursively get all the tasks for every project in your multi-project build. Try this.
rootProject.allprojects.collect { it.tasks }.flatten()
Ah so accessing the tasks container is enough to generate all the tasks?
Works great. Thanks!
This will return any and all tasks that are defined at the time this code is run. If run during the execution phase (in a task action) then it should be every task (unless some are creating during the execution of another task).
Alternatively, ‘TaskCollection’ is considered a “live” collection, so you can add actions that will be applied against every task, regardless of when it is created using something like ‘TaskContainer.all’.
It all depends on exactly what your use case is. Perhaps you can elaborate. If you need a complete list of every task at a given point of time, it could be unreliable since tasks can be dynamically created throughout the various phases of your build.
Is there a use case for creating tasks at execution time? That seems like a philosophical hack.
I am generating a Sublime Text 3 project file with attributes (including a “build system”) that represent the Gradle project.
I considered structuring the data in memory during the configuration phase then dumping it during the execution phase, however, I didn’t want a large structure sitting around useless for every build. (I guess that’s a non issue because the Task’s configuration block does not get executed unless you actually call the task, right? But what about someone else accessing the task… that would cause the task to be created and configured.) Regardless, that’s why I landed on iterating over the available tasks at execution time.
There may be a use case for creating tasks at execution time, but I’m not aware of a specific one off hand. It is probably very uncommon, I just wanted you to be aware that is a possibility, and there is nothing technically keeping you from doing so.
All tasks are configured (ie. their configuration closures evaluated) during the configuration phase, regardless of whether they are being executed as part of the current build. The reason for this is there is no way to know what the final task execution graph will be without evaluating the entire build script.
And that’s why I assumed they would all exist in the task container since they all get configured. I guess I was just missing the the part where I needed to get all the tasks from the subprojects too. Thanks for clearing that up.