Two Gradle builds running on a same machine, sharing the build cache location fails while running parallel #8375
Comments
|
Possibly related we also experience an issue when running parallel builds on CI |
|
I have the same problem，how to solve it？ |
|
We're also seeing this when running multiple builds concurrently on Jenkins using multiple Executors on a single Mac Pro |
|
This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution. |
|
We have similar issue. Two builds getting kicked off on same host with different branches. We see random errors. |
|
I think there is no straightforward solution to this, I am ending up with below workaround Another workaround to
in case of docker might need to mount that directory before doing copy. |
jjohannes
added
in:build-cache
and removed
a:investigation
|
Same problem here (not so frequent). Gradle 7.3 `
|
|
We also frequently encounter a this issue in Apache Beam, see: #14693 (comment). Looks like running two gradle builds on one machine causes unrecoverable cache corruption. |
|
We are also facing this issue in our CI/CD environment. Running 2 builds using Kubernetes Pods (each build has its own pod) and use the gradle home directory as a PersistentVolume is causing issues: Any solution? |
|
This is also a problem for me too, I don't really understand why gradle needs to lock anything in the cache because it's just downloading packages, it shouldn't matter how many gradle instances are downloading into that directory since the "lock" should be project specific on a per project basis, not gradle specific in a global context. |
|
We resolved this by using different GRALD_USER_HOME for different processes. |
ov7a
added
a:bug
a:investigation
|
Hi, @yunjizhong We are experiencing Gradle Cache Lock when building Gradle via Gitaction Runner on top of Kubernetes. Is your workaround above separating the Gradle home by service? |
Hi, @christhomas |
We have a worktree setup on top of a local git repository. Two different git branches(with minimal code diff) where checked out in git repo and worktree. Enabled the Build Cache for my gradle builds on both the branches. Also, location for the build cache(~/.gradle/caches/build-cache-1) is default. Upon triggering the builds on both the branches simultaneously, one of the gradle build fails with exception org.gradle.cache.LockTimeoutException
Expected Behavior
Both the builds should pass? If not, what is the recommendation for setting up the build cache on such setup?
Current Behavior
One of the build fails with org.gradle.cache.LockTimeoutException
Context
Setting up worktrees is common use case for us to support working on parallel releases of the software. We were testing out this option before we rollout with recommendations for such setup.
Steps to Reproduce (for bugs)
Your Environment
Gradle: Version 5.0
Windows 7 SP1 , 64-bit
GRADLE_OPTS="-Dorg.gradle.jvmargs=-Xmx5g -Dorg.gradle.caching=true"
###Stacktrace
The text was updated successfully, but these errors were encountered: