skip to content

What does the `--continue` flag change about how Gradle handles task failures, and what are the trade-offs?

level: middleimportance: should knowfreq 58%

answer

  1. default = fail-fast on first failure
  2. --continue keeps going
  3. skips only tasks depending on failed ones
  4. aggregates all failures, exits non-zero
  5. good for CI / multi-project

basics

~10 s

By default Gradle stops at the first task failure. --continue makes it keep executing every task that doesn't depend on a failed one, then report all failures at the end and exit non-zero.

solid answer

~40 s

Normally Gradle aborts the build the moment a task fails. `--continue` changes the failure policy: instead of stopping, Gradle keeps running every remaining task whose dependencies didn't fail, collects *all* failures, and reports them together at the end (still exiting with a non-zero code). The value is **surfacing every problem in one run** — especially in multi-project builds or CI, where you'd rather see all failing modules and all failing tests at once than fix-and-rerun repeatedly. The trade-off: tasks downstream of a failure are still skipped (their inputs are missing), so it doesn't run *everything*; and a longer, noisier run that does extra work after a failure can cost time. It pairs well with CI test reporting where aggregating failures is more useful than failing fast.

code

bash · 5 lines
bash
# Run all independent verification tasks, report every failure at once
gradle check --continue

# In a multi-project build, see failures across all modules in one run
gradle build --continue

go deeper

for a junior

Knows default is stop-on-first-failure and --continue keeps going then reports failures.

for a middle

Explains the dependency caveat (downstream tasks still skip) and the non-zero exit; positions it as a CI aggregation tool.

for a senior

Weighs the speed/noise trade-off vs fail-fast and chooses per pipeline stage; combines with test reporting.

for a principal

Defines CI policy: fail-fast for quick gates, --continue for full verification stages so one run yields the complete failure surface across modules.

## Default fail-fast behavior Gradle's default is **fail-fast**: the first task that throws causes the build to stop, and remaining work is abandoned. This is fast feedback but, in a large build, hides the fact that several other modules or tasks also would have failed. ## What `--continue` does ```bash gradle build --continue ``` With `--continue`, when a task fails Gradle does **not** stop. It continues executing every other task in the graph **except** those that (transitively) depend on the failed task — those still can't run because their inputs are missing. At the end, Gradle prints **all** collected failures and exits non-zero. Example in a multi-project build: if `:moduleA:test` fails, default Gradle stops there. With `--continue`, `:moduleB:test` and `:moduleC:test` still run, so you see failures across all three in one report. ## The dependency caveat `--continue` does not magically run downstream tasks. If `compileJava` fails, `test` (which needs the compiled classes) is still skipped — there's nothing to test. `--continue` only keeps **independent** branches of the graph going. ## Trade-offs - **Pro:** one run surfaces all failures — fewer fix-rerun cycles; ideal for CI where you want the full failure picture (all failing test modules, all lint issues). - **Con:** slower and noisier — you pay for extra work after a failure that you may have to discard; logs are longer. ## Where it fits Common CI pattern: run the verification build with `--continue` so a single pipeline run reports every broken module, then developers fix them in one pass. It is purely a **failure-handling** flag; it does not change *which* tasks are selected (that's selectors/`-x`) or whether they're forced (`--rerun-tasks`).

  • With `--continue`, if `compileJava` fails, will `test` still run?
    No. `test` depends on the compiled classes, so it's skipped — `--continue` only keeps tasks running that do NOT depend on the failed task.
  • Does `--continue` make the build exit with success?
    No. It still exits non-zero if any task failed; it just runs more tasks first and reports all failures together.
  • Why is `--continue` popular in CI?
    It surfaces every failing module/test in a single run, so developers can fix all problems in one pass instead of a fail-fast loop of fix-push-fail-again.

saying these in an interview costs you the question

  • Saying `--continue` runs even tasks that depend on the failed one.
  • Claiming the build exits successfully despite failures.
  • Confusing it with `-x` (excluding tasks) or `--rerun-tasks` (forcing execution).

context

resolving links…