Hey all, I have a gradle project with multiple sub...
# community-support
a
Hey all, I have a gradle project with multiple submodules and leveraging buildSrc to have common build logic for the multiple submodules. Now I'm trying to run multiple tasks in parallel to speed up my CICD via background processes like
./gradlew my-task1 &
and then grabbing the process ids and wait on them. The thing is I'm getting the following error
Copy code
Timeout waiting to lock build logic queue. It is currently in use by another Gradle instance.
Owner PID: 456
Our PID: 512
Owner Operation: 
Our operation: 
Lock file: /home/cicd/.gradle/noVersion/buildLogic.lock
I'm setting
org.gradle.daemon=false
in my
gradle.properties
file, however I believe this might be related with the buildSrc as it is shared and we might not be able to build it concurrently? Is that it? If so any ideias on how to do such Note: I'm not using
--parallel
because im calling same tasks with different values for parameters. Thanks in advance ✌️
v
I'm setting
org.gradle.daemon=false
in my
gradle.properties
file,
That's pretty irrelevant for multiple reasons. Nowadays this most often does not mean "don't use a daemon" but "use a one-off daemon and discard it after the build" because for real "no deamon" you would need to ensure that the CLI process is suitable as daemon process, including having the instrumentation agent configured. And whether a daemon is used or not is also irrelevant, because you get a complaint that multiple Gradle instances want to have the same lock and timed out, whether a daemon is used or not does not change this. To do this you might need to use different Gradle User Home directories, but this has other drawbacks of course, as you can imagine. My recommendation would be to make your build fit for configuration cache and use it, because then all tasks can run in parallel even within one project (if they don't rely on each other) other than
--parallel
which would anyway only run tasks of different projects in parallel. And to register multiple versions of
my-task
with the different properties set, so that you can run them with a single build invocation.
a
Hm not sure if I follow when u say
make your build fit for configuration cache
Isn't Gradle leveraging configuration cache by default and since I have shared build logic (buildSrc) this issue happens?
t
configuration cache is not active by default, its recommended to use it, but you have to either pass --configuration-cache or set org.gradle.configuration-cache=true In your gradle.properties. I can see why you are attempting to start multiple instances of the same build in parallel, but thats not really something gradle is designed for. Instead of calling the same task multiple times with different parameters you may want to register multiple tasks.. If thats no option, the other hackaround i can think of is you can maybe clone your repo into multiple different directories and run those in parallel
👍 1
v
Isn't Gradle leveraging configuration cache by default
Since recent versions Gradle recommends it by default and
init
generated new projects will follow that recommendation, but as @TheGoesen said, it is not enabled by default. I also did not suggest that enabling CC will enable you to run multiple Gradle build like you try, but it will usually safe much time on its own as all tasks can run in parallel even within one project. Combined with making your tasks distinct if possible, so that you can run them in one invocation, you hopefully have fast enough CI.
you can maybe clone your repo into multiple different directories and run those in parallel
I'm not so sure that will help. It is not a file within the project directory that is locked, but
/home/cicd/.gradle/noVersion/buildLogic.lock
, thus my suggestion to use different Gradle User Homes, even though I don't think that it is a particularly good idea.
and since I have shared build logic (buildSrc) this issue happens?
I think you would either way run into problems, whether you have shared build logic or not.
👍 1
a
Thanks for the feedback, guess then I won't be able to improve on this since we have to run the same task multiple times with different params which are dynamic and hence won't be able to register the tasks with bound params.
t
can you explain how your parameters are dynamic? I am curious what you are doing 😄
👆 1