> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-integration/troubleshooting-and-resources/ci-articles-and-faqs/articles/gradle-daemon.md).

# Gradle build and daemon issues

This article addresses some Gradle issues you might encounter with [Harness Continuous Integration (CI)](/continuous-integration/new-to-harness-ci/overview.md).

### Out of memory errors with Gradle <a href="#out-of-memory-errors-with-gradle" id="out-of-memory-errors-with-gradle"></a>

If a Gradle build experiences out of memory errors, add the following to your `gradle.properties` file:

```
-XX:+UnlockExperimentalVMOptions -XX:+UseContainerSupport
```

Your Java options must use [UseContainerSupport](https://eclipse.dev/openj9/docs/xxusecontainersupport/) instead of `UseCGroupMemoryLimitForHeap`, which was removed in JDK 11.

### Configure service dependencies in Gradle builds <a href="#configure-service-dependencies-in-gradle-builds" id="configure-service-dependencies-in-gradle-builds"></a>

You can use [Background steps](/continuous-integration/use-harness-ci/use-harness-ci/manage-dependencies/background-step-settings.md) to manage long-running service dependencies for Gradle builds. You can also launch services ad-hoc by using commands or flags (such as `--daemon`) in your steps.

#### Enable the Gradle daemon in builds <a href="#enable-the-gradle-daemon-in-builds" id="enable-the-gradle-daemon-in-builds"></a>

To enable the Gradle daemon in your Harness CI builds, include the `--daemon` option when running Gradle commands in your build scripts (such as in [Run steps](/continuous-integration/use-harness-ci/use-harness-ci/run-step-settings.md) or in build arguments for [Build and Push steps](https://developer.harness.io/docs/category/build-and-push)). This option instructs Gradle to use the daemon process.

Optionally, you can [use Background steps to optimize daemon performance](#manage-gradle-daemon-dependencies-to-improve-performance).

#### Manage Gradle daemon dependencies to improve performance <a href="#manage-gradle-daemon-dependencies-to-improve-performance" id="manage-gradle-daemon-dependencies-to-improve-performance"></a>

In Harness CI builds, each step runs in a separate container. If your pipeline has multiple steps that utilize Gradle through CLI, each step initiates a separate Gradle daemon (unless you explicitly set `--no-daemon`).

To optimize the build process and improve performance, use a [Background step](/continuous-integration/use-harness-ci/use-harness-ci/manage-dependencies/background-step-settings.md) to create a single Gradle daemon that can be used by all subsequent steps in the stage. This reduces the overhead of daemon startup and enhances the efficiency of the entire pipeline.

```yaml
              - step:
                  type: Background
                  name: Gradle_Daemon
                  identifier: Gradle_Daemon
                  spec:
                    connectorRef: YOUR_DOCKER_CONNECTOR_ID
                    image: gradle
                    shell: Sh
                    entrypoint:
                      - gradle
                    envVariables:
                      GRADLE_USER_HOME: /harness/.gradle
                      GRADLE_OPTS: "-Dorg.gradle.jvmargs=\"-Xms1024m -Xmx2048m\""
                    resources:
                      limits:
                        memory: 1G
```

### Parallel Gradle builds fail with "Currently in use by another Gradle instance" <a href="#parallel-gradle-builds-fail-with-currently-in-use-by-another-gradle-instance" id="parallel-gradle-builds-fail-with-currently-in-use-by-another-gradle-instance"></a>

Multiple parallel steps attempting to run `gradle build` (or other tasks) can cause the following error when multiple steps attempt to acquire lock on the same file:

```
Timeout waiting to lock checksums cache. It is currently in use by another Gradle instance.
```

To resolve this, set a custom `GRADLE_USER_HOME` directory for each daemon. Add the following commands before your first `gradle TASK` command in each step, and make sure the custom path *is not* in your stage's [shared paths](/continuous-integration/use-harness-ci/use-harness-ci/set-up-build-infrastructure/ci-stage-settings.md#shared-paths).

```
mkdir -p /tmp/gradlehome
export GRADLE_USER_HOME=/tmp/gradlehome
```

For more information and discussion on this Gradle error, go to:

* [Gradle Forums - Timeout waiting to lock checksums cache in Kubernetes pods](https://discuss.gradle.org/t/timeout-waiting-to-lock-checksums-cache-in-kubernetes-pods/44169)
* [StackOverflow - It is currently in use by another Gradle instance](https://stackoverflow.com/questions/21523508/it-is-currently-in-use-by-another-gradle-instance)

***

### Gradle daemon with Test Intelligence <a href="#gradle-daemon-with-test-intelligence" id="gradle-daemon-with-test-intelligence"></a>

The Test step generates a temporary init script in `/tmp/` that must be accessible to the Gradle daemon. If you run a Gradle daemon in a Background step and execute tests in a Test step, each step runs in a separate container. By default, containers do not share `/tmp/` directories, so the daemon cannot access the init script.

Without a shared `/tmp/` directory, Test Intelligence cannot collect the data it needs from the test run. This affects consecutive runs, because Test Intelligence relies on data from previous executions to determine which tests to select.

To resolve this, add `/tmp` to the stage's [shared paths](/continuous-integration/use-harness-ci/use-harness-ci/set-up-build-infrastructure/ci-stage-settings.md#shared-paths). This makes the `/tmp/` directory available across all containers in the stage, allowing the Background step daemon to access the Test Intelligence init script generated by the Test step.

```yaml
- stage:
    spec:
      sharedPaths:
        - /tmp
```

{% hint style="info" %}
If you do not use a Background step for the Gradle daemon, the Test step starts its own daemon within the same container and Test Intelligence works without additional configuration.
{% endhint %}

***

### Gradle version not compatible with Test Intelligence. <a href="#gradle-version-not-compatible-with-test-intelligence" id="gradle-version-not-compatible-with-test-intelligence"></a>

If you use Java with Gradle, Test Intelligence assumes `./gradlew` is present in the root of your project. If not, TI falls back to the Gradle tool to run the tests. As long as your Gradle version has test filtering support, it is compatible with Test Intelligence.

Add the following to your `build.gradle` to make it compatible with Test Intelligence:

```
// This adds HARNESS_JAVA_AGENT to the testing command if it's
// provided through the command line.
// Local builds will still remain same as it only adds if the
// parameter is provided.
tasks.withType(Test) {
  if(System.getProperty("HARNESS_JAVA_AGENT")) {
    jvmArgs += [System.getProperty("HARNESS_JAVA_AGENT")]
  }
}

// This makes sure that any test tasks for subprojects don't
// fail in case the test filter does not match.
gradle.projectsEvaluated {
        tasks.withType(Test) {
            filter {
                setFailOnNoMatchingTests(false)
            }
        }
}
```