Is there any reason why the configuration cache changes the order in which tasks are executed? The example here involves the

com.avast.gradle.docker-compose

plugin (version

0.17.18

). With the configuration cache disabled, it runs, e.g., in this order:

:lib1:composeUp

,

:lib1:test

,

:lib1:composeDown

,

:lib2:composeUp

,

:liib2:test

,

:lib2:composeDown

. But with the configuration cache enabled, it looks like it runs

:lib1:composeUp

and

:lib2:composeUp

in parallel first. Which can cause issues if there are port conflicts between those two tasks. I've attached an MCVE.

One of the big benefits of the configuration cache is, that each and every task even within the same project can run in parallel unless they have some ordering constraint or dependency.

That's an interesting way to use a shared build service. Huh.

That's one of its main intended use-cases actually afair. 😄 To represent a shared but limited resource.