This message was deleted.
# community-support
s
This message was deleted.
c
tasks will run in parallel where Gradle determines it’s appropriate to do so. Across project, and within a project (when configuration cache is enabled). Is there something about these tasks that isn’t parallel friendly? There isn’t a declarative way to ‘synchronize’, only a few hacky solutions depending on the nature of the challenge.
z
Copy code
execOperations.exec {
    commandLine(
        "./gradlew",
I don’t want to spin up a new gradle daemon for each
execOperations.exec
c
yea. if it’s absolutely necessary to do that (suggest avoiding it at all costs), you could synchronize on something to prevent overlaps. Perhaps a BuildService can help with that.
👍 1
e
why are you exec'ing gradle instead of using GradleBuild?
e
Copy code
tasks.register<GradleBuild>("publishChild") {
    setDir("child")
    setTasks(listOf(":assembleArtifact"))
    startParameter.setProjectProperties(mapOf("publish.version" to version))
}
or a composite build would usually be a better solution. even with a single daemon, they can have different AGP versions etc. (although obviously the same Gradle version)
z
With a single daemon, there can still need compile errors with incompatible AGP versions
I don't own the downstream app, this is why I need completely separate builds
With a single gradle daemon using the
GradleBuild
approach - wouldn't that transitively upgrade AGP versions? Or would it stay separate?
The same gradle version might be doable
v
GradleBuild
is a bad idea, especially if you don't know the downstream builds, because it does not support composite builds. As I said in the other thread, use the tooling API instead. Same effect, less problems, just a bit less convenient usage. In both approaches AGP should not be touched as the tasks run isolated. I'm right now not sure about Gradle version with
GradleBuild
as I didn't use it for long time, but using the tooling API you can use different Gradle versions. For running the tasks sequentially, use a shared build service. That is not a hacky solution, but a clean one. Define a build service with max parallel usage of 1 and make the tasks use it. One of the use-cases for shared build services is to represent a common restricted resource, in this case CPU / Memory for example.