Slackbot
11/02/2022, 12:32 AMChris Lee
11/02/2022, 12:36 AMZak Taccardi
11/02/2022, 12:37 AMexecOperations.exec {
commandLine(
"./gradlew",
I don’t want to spin up a new gradle daemon for each execOperations.exec
Chris Lee
11/02/2022, 12:39 AMephemient
11/02/2022, 1:11 AMZak Taccardi
11/02/2022, 1:16 AMephemient
11/02/2022, 1:30 AMtasks.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)Zak Taccardi
11/02/2022, 4:29 AMZak Taccardi
11/02/2022, 4:30 AMZak Taccardi
11/02/2022, 4:37 AMGradleBuild
approach - wouldn't that transitively upgrade AGP versions? Or would it stay separate?Zak Taccardi
11/02/2022, 4:38 AMVampire
11/02/2022, 8:08 AMGradleBuild
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.