we have a use case where we need to run the same build task (of JavaExec type) on multiple machines in the same workspace concurrently (where all worker machines mount a shared file system). What happens is that we run into the exception about file locking in .gradle:
" Could not create service of type FileHasher using GradleUserHomeScopeServices.createCachingFileHasher().
Timeout waiting to lock file hash cache"
I have found a number of questions both on this forum and stackoverflow on this exception suggesting that one needs to use a separate GRADLE_USER_HOME for each such build. This would be highly problematic for us since there are cases where we might want to run this job on 100+ machines at the same time which causes issues with disk size and problems cleaning up leftovers etc.
What makes this behavior strange is that we can run the job in parallel if all gradle processes run on the same machine. I assume this is because the gradle daemon handles this within one machine and realizes that it does not need an exclusive lock thorughout the process lifetime (?). But if the job is safe to run within one machine, why wouldn’t it be safe to run between multiple machines? I see no need for having to acquire the lock here.
With regards to solving this, I saw this feature suggestion (https://github.com/gradle/gradle/pull/6984), but there seems to be no progress on that one, so I don’t know if I’m to interpret that this is not going to happen or something else.
- Why does a JavaExec task ever need to lock the gradle user cache? I can understand why a compile task can’t be run in parallel, but what is there with a run-task that causes this limitation?
- Is there any way to set up my task so that it does not take out any locks in .gradle? E.g. force it to have no dependencies, set some commandline flag or some special code inside the build file?
Any other workarounds that we can use?