Executing tasks by name on multi-project

As per the documentation we can run tasks on all subprojects from the root Multi-Project Builds :

The command gradle test will execute the test task in any subprojects, relative to the current working directory, that have that task. If you run the command from the root project directory, you’ll run test in api , shared , services:shared and services:webservice . If you run the command from the services project directory, you’ll only execute the task in services:shared and services:webservice .

Could you please provide an example of the implementation, I assume we won’t use the dependsOn and getTaskByName to achieve this?

That is about executing manually, not programmatically.

1 Like

I am wondering mainly if there is a solution out of the box that allows to run the task from root on all subprojects or it needs to be configured with dependency.
For now I define the tasks as follow :

        tasks.register("testing") {
        description = "Runs the testing task on all subprojects"
        logger.lifecycle(" it's the root... ")
        dependsOn(subprojects.map { it.tasks.getByName("testing") })

and on the subproject

tasks.register("testing") {        
        description = "Runs the testing task on subproject"
         logger.lifecycle(" it's the from subproject... ")

Just don’t do it at all.
As the documentation you quoted yourself states.
If you run ./gradlew testing, it anyway runs all testing tasks in all sub projects where such a task exists.

Yes I tried this from the root and it worked. What if we would like to execute task on all sub-modules:

Root project 'multiproject'
+--- Project ':api'
+--- Project ':services'
|    +--- Project ':services:shared'
|    \--- Project ':services:webservice'
\--- Project ':shared'

How to enable ./gradlew :services:testing to run task on the services:shared and services:webservice ?

cd services
../gradlew testing

Of course you could also add task dependencies if you really need.
You could also do it like dependsOn(":services:shared:testing", ":services:webservice:testing"), the task paths are lazily resolved, so there will be no order-problem at configuration time.