I’m on big project that was started way before configuration cache was a thing. Or lazy API, or Kotlin DSL. I just noticed this task task("instrumentationReport") { dependsOn(project.getAllTasks(true).values().flatten().findAll { it.name.endsWith("generateReport") }) finalizedBy(tasks.na…

There is no direct way. All alternatives you showed are bad, because they either do cross-project configuration, or at least cross-project querying which is almost as bad. The only “proper” way is using string-y dependencies like subprojects.forEach { dependsOn("${it.path}:generateReport") } which…

Note, that getting a “global” merged report for all subprojects is what is wanted here. So the cost when running that task looks acceptable, ie even if it configures or query every suprojects. I understand your point though. Going into variants seems a bit early in this project. By the way there a…

So the cost when running that task looks acceptable It’s not only about cost, it is highly discouraged and bad practice. It will work against more sophisticated Gradle features and optimizations. For example the build will probably never become compatible with isolated projects that way. Also,…

Yeah by cost I was also including configuring. But I confer this task is only registered and run in CI. Which capability I meant the capability of “making” a task that depends on other sub-projects that have such task(s). I.e. having the ability to write something as simple as that subprojects.f…

I meant the capability of “making” a task that depends on other sub-projects that have such task(s). I.e. having the ability to write something as simple as that subprojects.forEach { dependsOn("${it.path}:generateReport", TaskExistance.IGNORED) } that would ignores when a task do not exists. May…

But taken all the time we talk here, you probably could have solved it the proper way already. :smiley: I have an acceptable workaround for now, but I have need to tackle bigger issues than this one, so it’s not yet prioritized to have the “best” solution there. Thanks for the discussion and the …

For the addRule I was thinking of things like handling tasks like :foo:allTests, where the foo project has different test suites, and one want to run all of them. That’s not a use-case for a task rule. That should simply be val allTests by tasks.registering { dependsOn(tasks.withType<Test>(…

[image] Vampire: did I mention artifact/variant-aware resolution? :slight_smile: OK I get the message :sweat_smile: Also, I forgot to mention but I also saw some folks passing glob style paths, e.g. :foo:b*:compile*Java. The add rule discovers projects and tasks that match the path glob. And…

Fancy. Except that it does not work for the project part

Depending on specific subprojects tasks in a lazy way

Help/Discuss

bric3 (Brice Dutheil) October 8, 2025, 4:43pm 10

Found the place that suggested the above usage for addRule: How to run a task for a subset of multiproject-build

Topic		Replies	Views
Lazy task will be configured even if it should not Help/Discuss	3	774	July 29, 2021
Adding dependency for tasks which are part of subprojects Old Forum Archive	2	797	December 4, 2014
Multi project builds and task foo(dependsOn: 'x') syntax? Old Forum Archive	3	22915	October 31, 2011
Extra side-effects of Project.getTasksByName()? Help/Discuss	24	2426	October 5, 2020
Groovy => Kotlin - taskProvider dependsOn type problem Help/Discuss	5	229	November 29, 2024

Depending on specific subprojects tasks in a lazy way

Related topics