https://gradle.com/ logo
Join Slack
Powered by
Is the order of task execution documented somewher...
# community-support
m
Is the order of task execution documented somewhere in Gradle? I understand task dependencies are always honored but given 2 tasks that are elligible for execution (they have all their dependencies ready), which one is executed first?
v
I don't think this is documented, or guaranteed. And it also shouldn't matter. If it matters, then it should be defined by a task ordering rule is task dependency. Iirc it depends on multiple things, including the other of tasks you specify on the commandline.
m
Reason I'm asking is that it may change the duration of the critical path in my build. Say I have a very long task that unlocks a bunch of other tasks in the graph, I'd like this one to be executed first so that it unlocks the rest of the build
Formally speaking, it's a scheduling optimisation problem
v
What do you mean by "unlock"? And why can't those other tasks use 
dependsOn
, 
mustRunAfter
, or 
shouldRunAfter
? As those are the ways to influence the ordering, which depending on the actual semantics needed.
m
It's not only the dependencies, it's also the weight of each node (task)
Let me build an example
Let's assume this graph:
Copy code
A --> B
B --> E
B --> F
A --> C
C --> F
A --> D
And assume that the nodes have those weights (C is longuer than the otheres):
Copy code
A(1)
B(1)
C(2)
D(1)
E(1)
And assume you have 2 workers
If you start by executing D and E in parallel, C cannot start until the next tick, meaning your critical path is now 4
Wait, no that doesn't work
But I'm sure there are cases where it does 😄
Alright, I have edited the example, I think it works now!
mermaid-diagram-2025-03-26-170758.png
Copy code
1: run D & E
2: run F
3: run C & B
4: continue C
5: run A
vs
Copy code
1: run E & F
2: run B & C
3: run D, continue C
4: run A
In the first case, your build takes 5 ticks. In the second case, it takes only 4 (much better!)
v
Step 2 in first case doesn't work as b depends on d. 2 would be only F and 3 B and C. But point taken, yes.
👍 1
But to do such a calculation correctly, you would also need to know how long each task needs (its weight)
You can hardly assume all tasks need the same time
Maybe that could be remembered from previous executions though
Maybe Gradle even does that? 🤷‍♂️ :-)
j
I think I've read somewhere that all things being equal tasks would be executed in alphanumerical order of task path, but I'm not sure this is still true and it's certainly not guaranteed. It looks like keeping some history of build times would be required to implement this idea, or maybe with an API to make it possible to manually tweak task weights. Not sure it's really useful if you have enough parallelism on your build runners, but that may help on constrained environments where build times are already going to be significantly longer.
👀 1
m
Step 2 in first case doesn't work as b depends on d. 2 would be only F and 3 B and C.
Right!
> It looks like keeping some history of build times would be required to implement this idea, or maybe with an API to make it possible to manually tweak task weights. Sounds like a cool develocity feature 🙂 (remembering from the previous runs)
Parallelism only takes you so far, your resources are ultimately bounded
(I have yet again updated the example, I think it's good now 😅 )
j
it makes sense for local builds too, developer laptops aren't that great at parallelism
➕ 1
v
I think I have 16 cores or so, so parallelism is fine. But still the feature could make sense. I agree that Develocity should not really concerned. Just remember the last execution times in 
.gradle
and consider it for the scheduling weight.
If that is not done already and you open a feature request, please share the link
m
I think I have 16 cores or so, so parallelism is fine. But still the feature could make sense.
I'm usually memory-bound more than CPU bound
I agree that Develocity should not really concerned.
It could act as a distributed registry for average weight. Even if you have nothing on your machine, develocity has knowledge about past executions on other machines (although the hardware might introduce variance...)
If that is not done already and you open a feature request, please share the link
https://github.com/gradle/gradle/issues/32855
v
It could act as a distributed registry for average weight.
Sure, as an additional / alternative source 👍
You forgot to mention 2 workers only. And you should better use the linen link to this thread as it will not become inaccessible like the Slack link.
👍 1
🙏 1
m
updated
👌 1
5 Views
Open in Slack
PreviousNext
Powered by