I have ran into this situation where I have following task dependencies:
taskA() { dependsOn taskB, taskC }
taskD() { dependsOn taskE, taskF }
very often, I need to specify taskD.mustRunAfter taskA and I would expect that taskE, taskF would run after taskB and taskC. However, when I let gradle build run in parallel it’s not guarantee that taskE and taskF would run after taskB and taskC.
At the moment, I have to specify taskE.mustRunAfter taskB, taskE.mustRunAfter taskC, taskF.mustRunAfter taskB, taskF.mustRunAfter taskC to get over this. This is quite lots configuration boiler code that I need to type.
Note that taskA and taskD contain different build logic and it doesn’t make sense to specify taskD.dependsOn taskA.
I wonder if there’s better way to specify ordering between taskD and taskA (more specifically, ensure ordering between subtasks of taskD and subtasks of taskA)
This simplifies things a bit, but if aggregateTaskD contains more tasks (like 10 subtasks), It stills quite a bit of boiler code. Is there anything simpler like aggregateTaskD.mustRunAfter aggregateTaskA (this would force all subtasks of D to run after all subtasks of A)? would aggregateTaskD.dependsOn.mustRunAfter aggregateTaskA.dependsOn work?
In one particular case, we need to save application configuration and re-apply the configuration once the gradle finished building artifacts and deploy the artifacts. Essentially, there are 4 steps:
task 1) save old configuration (with bunch of subtasks)
task 2) rebuild the application (with bunch of subtasks)
task 3) deploy the application artifacts locally
task 4) re-apply the old configuration on top of the new deployed artifacts
In this case, we would like to have task2.mustRunAfter task1
It really doesn’t make sense to me to specify task2.dependsOn task1 as they have different purpose and they are not related. Furthermore, task2 is being reused by some other tasks (let’s say task7) and if we specify task2.dependsOn task1, when task7 is executed it would also execute task1 (save old configuration) which we don’t want.
I hope that would explain the use case a little bit more for you. Let me know if you need some more information.