skip to content

Execution Control Flags

4 roadmaps6 questions

--continue, --offline, --dry-run, --rerun-tasks, and task exclusion for forcing, tolerating, or skipping work. Interviewers ask which flag you reach for when CI dies on the first failing module.

on this pageshow

explore

questions

6

How do you exclude a specific task from a Gradle build invocation, and what exactly does excluding it do to its dependencies?

level: juniorimportance: must knowfreq 70%

answer

  1. -x / --exclude-task
  2. removed from task graph before execution
  3. unshared dependencies pruned too
  4. shared deps still run
  5. per-invocation, not script edit

basics

~10 s

Use -x or --exclude-task with the task name, e.g. gradle build -x test. Gradle removes that task — and any task needed only by it — from the execution graph for this run.

solid answer

~40 s

You pass `-x <taskName>` (long form `--exclude-task <taskName>`) to drop a task from the current invocation: `gradle build -x test` builds everything but skips `test`. Gradle resolves the full task graph first, then removes the excluded task. Crucially, a dependency of the excluded task is also dropped **only if nothing else in the graph needs it** — shared dependencies still run. The match is by task name and can be qualified by path (`:app:test`) to target one project in a multi-project build. Excluding only affects this single invocation; it does not edit the build script. It is the standard way to say "do the whole flow except this one slow/flaky step" without changing wiring.

code

bash · 8 lines
bash
# Build everything except tests
gradle build -x test

# Exclude in just one subproject of a multi-project build
gradle build -x :app:test

# Exclude multiple tasks
gradle build -x test -x checkstyleMain

go deeper

for a junior

Know the flag name and the canonical build -x test; can state it skips that task for this run.

for a middle

Explains the dependency-pruning rule (only unshared deps dropped) and path-qualified exclusion in multi-project builds.

for a senior

Contrasts -x with permanent disabling (enabled=false/onlyIf) and warns against excluding tasks the rest of the graph depends on.

for a principal

Frames -x as a local iteration tool, not a CI policy mechanism; pushes durable opt-outs into build logic or build-cache strategy rather than ad-hoc CLI flags scattered in pipelines.

## What `-x` / `--exclude-task` does When you run `gradle build`, Gradle first computes a **task execution graph** (a directed acyclic graph): `build` depends on `check`, which depends on `test`, which depends on `testClasses`, and so on. The `-x` flag (long form `--exclude-task`) tells Gradle to remove a named task from that graph *before* execution begins. ```bash gradle build -x test ``` This runs the entire `build` flow but skips `test`. ## The dependency-pruning rule The subtle part: excluding a task also prunes tasks that exist **solely** to satisfy the excluded one. If `test` is the only thing that depends on `compileTestJava`, then `-x test` drops `compileTestJava` too. But if another retained task also needs it, it stays. So exclusion prunes *only the unshared subgraph* below the excluded task. ## Naming and matching - You can use the **unqualified name** (`-x test`) — it matches in every project of a multi-project build. - You can **fully qualify** the path (`-x :app:test`) to exclude in just one project. - Gradle supports **camelCase abbreviation** for the task you run, but for `-x` use the real task name. ## Repeatable `-x` can appear multiple times: `gradle build -x test -x checkstyleMain` excludes both. ## What it is NOT - It is **not** the same as `--dry-run` (which prints the graph but runs nothing). - It does **not** modify `build.gradle` — it is per-invocation only. To permanently disable, set `task.enabled = false` in the build script instead. ## When to reach for it Typical uses: `-x test` for a fast packaging build, `-x` a slow integration or lint task during local iteration, or skipping a known-flaky task while you investigate it.

  • If you run `gradle build -x compileJava`, what happens?
    `compileJava` is needed by many downstream tasks (jar, test, etc.), so excluding it makes the graph unsatisfiable — Gradle will still try, but tasks depending on its outputs fail. `-x` is meant for leaf-ish or optional tasks, not core compile steps everything depends on.
  • How would you make a task permanently skipped rather than per-invocation?
    Set `tasks.named("someTask") { enabled = false }` in the build script, or use an `onlyIf {}` predicate. `-x` is only for one-off command-line exclusion.

saying these in an interview costs you the question

  • Claiming `-x` edits the build file or disables the task permanently.
  • Saying all dependencies of the excluded task are always removed — shared ones are retained.
  • Confusing `-x` with `--dry-run` (which runs nothing at all).

context

resolving links…

open as a page

What does `--rerun-tasks` do, and how does it differ from `clean build`?

level: middleimportance: must knowfreq 60%

basics

~10 s

--rerun-tasks forces every selected task to execute, ignoring up-to-date checks and the build cache, without deleting outputs. clean build instead deletes the build/ directory first, then runs.

open as a page

What does the `--dry-run` flag do in Gradle, and when is it useful?

level: juniorimportance: should knowfreq 55%

basics

~10 s

--dry-run (-m) makes Gradle compute and print the ordered list of tasks it would run, each marked SKIPPED, without actually executing any of them. It's a safe preview of the execution graph.

open as a page

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

level: middleimportance: should knowfreq 58%

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.

open as a page

What does the `--offline` flag do, and how does it interact with Gradle's dependency cache?

level: middleimportance: should knowfreq 50%

basics

~10 s

--offline tells Gradle never to access the network during the build. It resolves dependencies purely from the local dependency cache and fails if a required artifact or metadata isn't already cached.

open as a page

How would you combine Gradle execution-control flags to reproduce a flaky CI failure locally, and how do they interact?

level: seniorimportance: should knowfreq 40%

basics

~10 s

Combine them by intent: --rerun-tasks forces fresh execution, --continue surfaces all failures, --offline removes network variance, and -x drops unrelated slow tasks — e.g. gradle check --rerun-tasks --continue --offline -x lint.

open as a page