Gradle build and daemon issues

These are some Gradle issues you might encounter with Harness CI.

This article addresses some Gradle issues you might encounter with Harness Continuous Integration (CI).

Out of memory errors with Gradle

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 instead of UseCGroupMemoryLimitForHeap, which was removed in JDK 11.

Configure service dependencies in Gradle builds

You can use Background steps 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

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 or in build arguments for Build and Push steps). 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

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 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.

              - 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"

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.

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

• StackOverflow - It is currently in use by another Gradle instance

---

Gradle daemon with Test Intelligence

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. 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.

- stage:
    spec:
      sharedPaths:
        - /tmp

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.

---

Gradle version not compatible with Test Intelligence.

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)
            }
        }
}