Gradle and CI/CD: Task Cancellation and Timeout Interoperability

Question

Gradle and CI/CD: Task Cancellation and Timeout Interoperability
When a Gradle build runs inside a CI/CD pipeline, developers often rely on pipeline timeouts to abort long‑running jobs. However, Gradle itself lacks a built‑in per‑task timeout API, and cancellation of the Gradle process (e.g., via Ctrl+C or SIGINT) does not automatically terminate child processes started by tasks such as JavaExec. The Gradle daemon can be stopped after a period of inactivity, but that idle timeout does not affect running tasks. Consequently, builds can leave orphaned processes or incomplete cleanup, especially on Windows where SIGINT handling differs.
The core goal is to determine a reliable, declarative way for developers to specify maximum runtimes per task and to ensure that both Gradle and the CI/CD system cooperate to terminate any spawned processes gracefully.
Key uncertainties include whether Gradle should expose a native task.timeout property, how child processes should be signaled on cancellation, and how CI pipeline timeouts can be aligned with Gradle’s daemon idle timeout without causing resource leaks.
Unresolved questions:

Should Gradle expose a native task‑level timeout configuration?
What mechanism best ensures child processes spawned by Gradle tasks are terminated when the build is cancelled?
How can CI/CD pipeline timeouts be coordinated with Gradle’s daemon idle timeout to avoid orphaned processes?

Tasadduq Burney · Answer

What’s possible today for per‑task timeouts in Gradle
Gradle does not expose a declarative task.timeout property that automatically limits execution time and propagates cancellation to all spawned child processes. The build engine relies on the JVM’s default signal handling and the CI system’s process‑group management. When a CI pipeline enforces a timeout, it typically sends SIGTERM or SIGKILL to the top‑level Gradle process, which may terminate the JVM but does not guarantee that foreground or background tasks started via JavaExec, Exec, or forked workers stop gracefully.
Likely explanation vs confirmed facts

CI timeout behavior: Most CI platforms (GitHub Actions, GitLab CI, Jenkins) kill the entire process group when the build timeout expires. This often results in an abrupt SIGKILL, bypassing Gradle’s internal shutdown hooks.
  Gradle daemon shutdown: The --stop flag sends a graceful shutdown request to the daemon. However, this only affects the daemon itself; running tasks may continue or leave orphaned JVM processes, especially on Windows where SIGINT handling differs from Unix.
  Task‑level timeout absence: No native Gradle property exists to set a maximum runtime per task. Workarounds rely on external scripting, JVM arguments, or custom task listeners.

Minimal steps to mitigate orphaned processes

Identify the CI platform’s timeout mechanism and whether it sends SIGTERM before SIGKILL, and what signal is delivered to the process group.
  Configure the Gradle daemon JVM to handle shutdown signals reliably: ensure the daemon version is 6.x or newer, where --stop response is more predictable.
  Use gradle --stop in a post‑build script or CI teardown step to target the daemon rather than killing the shell process directly.
  For long‑running tasks, consider wrapping the task body in a signal‑aware wrapper that catches SIGTERM and performs cleanup before exiting.

To tailor the recommendation for your environment, please specify: which CI platform you are using and your Gradle version.

Gradle and CI/CD: Task Cancellation and Timeout Interoperability

Gradle and CI/CD: Task Cancellation and Timeout Interoperability

1 answer

What’s possible today for per‑task timeouts in Gradle

Likely explanation vs confirmed facts

Minimal steps to mitigate orphaned processes

Your perspective belongs here.

1 question comment

Gradle ExecSpec Timeout: A Practical Inter‑Process Safeguard