This message was deleted.
# community-support
s
This message was deleted.
v
You should leverage configuration cache, then even all tasks that do not depend on each other can be run in parallel, not only ones from different projects. :-) But regarding your question, without parallel and without CC there can still be parallelism if tasks use the worker API.
🀯 1
r
I thought the parallel flag was required to even to leverage the worker API! This is quite surprising. Thanks for your answer!
And yes, CC was my next step in this project (actually I zoomed out to execution not only to show the parallel case, but also because conf phase is embarrassing πŸ™ˆ), but there are still some violations that we need to solve first. πŸ™‚
v
Nope,
--parallel
is only so that whole tasks of different projects can be executed in parallel. Worker API work items can run in parallel even work items of the same task. And also other tasks can run while the work items are processed if the task is not implemented to wait for them and the other task is not a dependee.
thank you 1
πŸ‘ 1
e
there is a separate
--max-workers
parameter if you want to limit parallelism there
πŸ‘ 1
r
Thanks @ephemient, but this extra parallelization is great, so I am not interested in disabling it. It simply shocked me to see multiple tasks executed in parallel with the flag disabled. Actually I wrongly assumed in the past that it was enabled already due this reason when looking the timeline. My purpose with this thread was simply to understand how it was possible πŸ™‚
πŸ‘Œ 1
Now that we are all gathered here… I have a follow-up question if you don’t mind:
You should leverage configuration cache, then even all tasks that do not depend on each other can be run in parallel, not only ones from different projects
Is this true even when the configuration is not reused from the cache? So, does this improvement also works in the first run when cc is enabled? We discussed with some teammates about this in the past and assumed that Configuration Cache was not worth for ephemeral builds in the CI, but if these improvements are there even if configuration is not skipped, it might be worth to enable it anyway even if we are not going to reuse it πŸ‘€
e
afaik yes: even with a cold cache, Gradle will take the state after configuration, and execute as if it had loaded state from configuration cache
thank you 1
v
Yes πŸ™‚
thank you 1
r
Thanks, this is really helpful! πŸ™‚
πŸ‘Œ 1