What does `--rerun-tasks` do, and how does it differ from `clean build`?
answer
- ignores up-to-date + build cache
- forces all selected tasks
- does NOT delete outputs
- clean deletes build/ first
- diagnostic, not CI default
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.
solid answer
~40 s`--rerun-tasks` tells Gradle to ignore incremental skipping for this invocation: every selected task runs even if its inputs/outputs are unchanged, and build-cache hits are bypassed. It does **not** delete existing outputs — tasks overwrite them. `clean build` is different: `clean` is a real task that *deletes* the build output directory, then `build` runs from an empty state. So `--rerun-tasks` is a softer, more targeted reset that still leaves stale or now-unreferenced files on disk, whereas `clean` guarantees a pristine output tree but is slower and discards incremental state for everything. Reach for `--rerun-tasks` when you suspect up-to-date logic is wrong or want to validate a task actually does its work; reach for `clean` when leftover artifacts could be contaminating the build.
code
bash · 5 lines# Force every selected task to run, ignoring up-to-date and cache
gradle build --rerun-tasks
# Contrast: delete outputs first, then build from scratch
gradle clean buildgo deeper
Knows it forces tasks to run again instead of being skipped as up-to-date.
Distinguishes it from clean build (no deletion vs deletion) and notes it also bypasses the build cache.
Explains the orphaned-output gap and chooses the right tool per scenario; treats it as diagnostic, not policy.
Sets org-level guidance: prefer ephemeral CI workspaces/clean for reproducibility, reserve --rerun-tasks for debugging cache/up-to-date correctness.
## Incremental builds and why a force flag exists Gradle skips work via **up-to-date checks** (a task whose declared inputs and outputs are unchanged is `UP-TO-DATE`) and the **build cache** (a task whose input hash matches a cached entry is restored as `FROM-CACHE`). This makes builds fast but means a task may not actually run. `--rerun-tasks` disables both for the current invocation: ```bash gradle build --rerun-tasks ``` Every selected task executes — no `UP-TO-DATE`, no `FROM-CACHE`. It is the global, all-tasks counterpart to the per-task `--rerun` option (which targets a single task and is covered separately under task input/output rerun semantics). ## `--rerun-tasks` vs `clean build` | Aspect | `--rerun-tasks` | `clean build` | |---|---|---| | Deletes outputs first? | No — overwrites in place | Yes — `clean` deletes `build/` | | Forces execution? | Yes, all selected tasks | Yes, because outputs are gone | | Stale/orphan files removed? | No | Yes | | Speed | Faster (no delete, may reuse dirs) | Slower (fresh from empty) | Key insight: `--rerun-tasks` forces *execution* but not a *clean slate*. If a previous run left an orphaned class file or resource that no current task produces, `--rerun-tasks` leaves it there; `clean` removes it. ## When to use which - **`--rerun-tasks`**: diagnosing suspected-wrong up-to-date checks, confirming a custom task truly runs, reproducing a result without the delete cost. - **`clean`**: when stale outputs could corrupt the build (renamed/removed sources, packaging artifacts), or when you need a reproducible from-scratch result. ## Caution `--rerun-tasks` defeats the performance benefit of incremental builds — it's a debugging/diagnostic tool, not something to bake into CI by default (CI reproducibility is better served by ephemeral workspaces or `clean`).
- Does `--rerun-tasks` ignore the build cache as well as up-to-date checks?Yes — it bypasses both. Tasks won't show UP-TO-DATE and won't be restored FROM-CACHE; they actually execute.
- Why might `clean build` catch a bug that `--rerun-tasks` misses?`clean` deletes stale/orphaned outputs from prior runs. `--rerun-tasks` overwrites in place but leaves files no current task produces, so a packaging bug caused by a leftover artifact only shows after a true clean.
- Is `--rerun-tasks` a good default for CI?No — it defeats incremental and cache speedups. CI reproducibility is better achieved with ephemeral checkouts or an explicit `clean`; `--rerun-tasks` is a local diagnostic flag.
saying these in an interview costs you the question
- Saying `--rerun-tasks` deletes the build directory — it does not.
- Claiming it only bypasses up-to-date but not the build cache (it bypasses both).
- Recommending it as a standing CI flag for 'safety'.