# Running integration tests in parallel on a CI server (GRADLE-2795, GRADLE-3200)

**URL:** <https://discuss.gradle.org/t/running-integration-tests-in-parallel-on-a-ci-server-gradle-2795-gradle-3200/10420>\
**Category:** Bugs\
**Created:** [July 3, 2015, 7:06am UTC](https://discuss.gradle.org/t/running-integration-tests-in-parallel-on-a-ci-server-gradle-2795-gradle-3200/10420 "2015-07-03T07:06:42Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Moe](https://avatars.discourse-cdn.com/v4/letter/m/ad7895/32.png) [@Moe](https://discuss.gradle.org/u/Moe)\
**Post date:** [July 3, 2015, 7:06am UTC](https://discuss.gradle.org/t/running-integration-tests-in-parallel-on-a-ci-server-gradle-2795-gradle-3200/10420/1 "2015-07-03T07:06:42Z")

</div>

Continuing the discussion from [Timeout waiting to lock artifact cache](https://discuss.gradle.org/t/timeout-waiting-to-lock-artifact-cache/2545/24):

> [@Timeout waiting to lock artifact cache](https://discuss.gradle.org/t/timeout-waiting-to-lock-artifact-cache/2545/24):
>
> What we don’t know is exactly what the lock holding build is doing that prevents it from relinquishing the lock for another build.

I have to bring this old issue up again since it’s currently blocking us from using gradle for our CI build. I can reliably reproduce this issue on our CI server and I might be able to spend some time trying to find the root cause. Is there any easy way to find out what the process holding the lock is doing while the others are waiting?

---

<div class="post-metadata">

**Author:** ![Moe](https://avatars.discourse-cdn.com/v4/letter/m/ad7895/32.png) [@Moe](https://discuss.gradle.org/u/Moe)\
**Post date:** [July 3, 2015, 6:47pm UTC](https://discuss.gradle.org/t/running-integration-tests-in-parallel-on-a-ci-server-gradle-2795-gradle-3200/10420/2 "2015-07-03T18:47:17Z")

</div>

Some more information: I’m currenly trying to run 8 sets of integration tests (8 different subprojects in the multi-project build) in parallel on different machines. GRADLE\_USER\_HOME is on a NFS share that all machines share. Whenever I try to start those 8 jobs in parallel, 7 of them time out waiting for either `.gradle/caches/2.4/plugin-resolution/cache.properties.lock` (queryPluginMetadata - read) or `.gradle/caches/modules-2/modules-2.lock` (resolving the configuration of the `common` subproject).

Using different GRADLE\_USER\_HOME directories is not an option, since that would slow down the build considerably.

---

<div class="post-metadata">

**Author:** ![Moe](https://avatars.discourse-cdn.com/v4/letter/m/ad7895/32.png) [@Moe](https://discuss.gradle.org/u/Moe)\
**Post date:** [July 6, 2015, 5:28pm UTC](https://discuss.gradle.org/t/running-integration-tests-in-parallel-on-a-ci-server-gradle-2795-gradle-3200/10420/3 "2015-07-06T17:28:46Z")

</div>

After a bit more of testing, it seems like NFS being slow isn’t the only problem. I just tried to run all integration tests in parallel on a single machine without touching NFS, which fixed the lock timeouts, and ran into [https://issues.gradle.org/browse/GRADLE-3200](https://issues.gradle.org/browse/GRADLE-3200%20GRADLE-3200).

It seems like Gradle currently has a lot of issues with setups like ours, where multiple Gradle tasks have to run in parallel on one or multiple CI servers. 8 is not a huge number and our project is not insanely large.

As a workaround, for now, I will try to use 1 GRADLE\_USER\_HOME per Jenkins job, but I really wish there was a better solution.