skip to content

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

level: juniorimportance: should knowfreq 55%

answer

  1. -m / --dry-run
  2. prints ordered tasks, all SKIPPED
  3. config phase still runs
  4. no execution, no outputs
  5. preview before destructive run

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.

solid answer

~40 s

`--dry-run` (short `-m`) runs the configuration phase, builds the task execution graph, and prints every task that *would* execute in order — each tagged `SKIPPED` — but executes **none** of their actions. It's the quickest way to answer "what will this command actually do?" before committing, especially when combined with task selectors or `-x` to verify your exclusions and ordering are correct. Because configuration still runs, configuration-time side effects and errors will still surface, so it validates wiring but not task behavior. Use it to preview a release or destructive task chain, to confirm a task name resolves, or to inspect dependency ordering without paying execution cost.

code

bash · 5 lines
bash
# Preview the task graph for build, nothing executes
gradle build --dry-run

# Combine: preview the graph with tests excluded
gradle build -x test -m

go deeper

for a junior

Knows --dry-run/-m lists tasks marked SKIPPED and runs nothing.

for a middle

Explains that configuration still runs, so wiring/selectors are validated but behavior is not.

for a senior

Uses it deliberately to preview destructive/release chains and to debug task ordering and dependsOn wiring.

for a principal

Recommends dry-run as a guardrail step in risky pipelines and understands its interaction with the configuration cache (entries may still be stored).

## The phases and where `--dry-run` stops A Gradle invocation has three phases: **initialization** (which projects), **configuration** (build the task graph by configuring tasks), and **execution** (run each selected task's actions). `--dry-run` (alias `-m`) lets the first two phases run normally, then prints the resulting task list — each line marked `SKIPPED` — and stops short of executing any task action. ```bash gradle build --dry-run ``` Output is the **ordered** set of tasks Gradle would run: ``` :compileJava SKIPPED :processResources SKIPPED :classes SKIPPED :jar SKIPPED ... :build SKIPPED ``` ## What it verifies — and what it does not - It **verifies** which tasks are selected, their order, and that names/selectors resolve. Great for checking `-x` exclusions or a custom task chain. - It does **not** verify task *behavior* — no inputs are read, no outputs produced, no up-to-date checks decided (everything just shows SKIPPED). - **Configuration still runs.** So a misconfigured plugin or a script that has side effects at configuration time will still trigger those. With the configuration cache, a cache entry may even be stored. ## Common uses - Preview a **destructive or release** pipeline (publish, deploy, clean+overwrite) before running it for real. - Confirm a typo-prone **task selector** resolves to what you expect. - Inspect **ordering** and the effect of `dependsOn` / `mustRunAfter` wiring. ## Relation to neighbors `--dry-run` is the "run nothing" end of the spectrum; `--rerun-tasks` is the "run everything, ignore up-to-date" end; `-x` removes specific tasks; `--continue` changes failure handling. They compose: `gradle build -x test --dry-run` previews the graph with tests excluded.

  • Does `--dry-run` run the configuration phase?
    Yes. Initialization and configuration both run; only the execution phase is skipped. So configuration-time errors and side effects still occur — it validates wiring, not task behavior.
  • How is `--dry-run` different from `--rerun-tasks`?
    Opposites: `--dry-run` executes no task actions (everything SKIPPED), while `--rerun-tasks` executes all selected tasks while ignoring up-to-date/incremental skipping.

saying these in an interview costs you the question

  • Saying `--dry-run` skips the configuration phase — it does not.
  • Claiming it produces outputs or runs up-to-date checks.
  • Treating it as a way to 'test' that a task works correctly.

context

resolving links…