skip to content

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%

answer

  1. each flag = separate axis
  2. rerun-tasks=force, continue=failures, offline=net, -x=graph
  3. dry-run overrides execution flags
  4. warm cache needed for offline
  5. compose into one precise command

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.

solid answer

~40 s

Each execution-control flag governs a different axis, so they compose cleanly. To reliably reproduce a flaky CI failure locally I'd think: force a clean execution (`--rerun-tasks` so nothing is silently UP-TO-DATE or FROM-CACHE), see every failure not just the first (`--continue`), eliminate network as a variable (`--offline`, assuming the cache is warm), and trim noise by excluding unrelated heavy tasks (`-x`). A typical command: `gradle check --rerun-tasks --continue --offline -x integrationTest`. I'd often add `--dry-run` first to confirm the graph is what I expect before the real run. The mental model: `--rerun-tasks` = *force execution*, `--continue` = *failure handling*, `--offline` = *dependency resolution / network*, `-x` = *graph selection*, `--dry-run` = *preview only*. Because they target orthogonal concerns they don't conflict — except `--dry-run` overrides execution-side flags since nothing actually runs.

code

bash · 5 lines
bash
# Preview first
gradle :service:check --dry-run

# Reproduce: force fresh run, all failures, no network, skip slow suite
gradle :service:check --rerun-tasks --continue --offline -x integrationTest

go deeper

for a junior

Can name the flags individually but may not see them as orthogonal axes.

for a middle

Combines a couple correctly (e.g. --rerun-tasks --continue) and explains intent.

for a senior

Builds a precise minimal command for a real reproduction, explains axis orthogonality and the dry-run dominance subtlety.

for a principal

Codifies which flags belong in CI policy vs local diagnostics, and ties offline use to cache-seeding / mirror strategy across the org.

## Orthogonal axes The execution-control flags each touch a separate concern, which is why they compose: | Flag | Axis | Effect | |---|---|---| | `--rerun-tasks` | force execution | ignore up-to-date + build cache; run all selected tasks | | `--continue` | failure handling | don't stop at first failure; aggregate all | | `--offline` | dependency/network | resolve from local cache only; no remote access | | `-x` / `--exclude-task` | graph selection | remove a task (and its unshared deps) from the run | | `--dry-run` (`-m`) | preview | print the task graph; execute nothing | ## A reproduction recipe Suppose CI intermittently fails `:service:test` and you can't reproduce it because locally those tests show `UP-TO-DATE` or `FROM-CACHE`. Build up the command: ```bash # 1. Confirm what would run gradle :service:check --dry-run # 2. Real run: force fresh execution, surface all failures, # remove network variance, skip the slow unrelated suite gradle :service:check --rerun-tasks --continue --offline -x integrationTest ``` - `--rerun-tasks` defeats incremental skipping so the suspect tests actually execute. - `--continue` ensures that if several tests/modules fail you see them all in one pass. - `--offline` removes 'a transitive snapshot changed' as a hidden variable (cache must be warm first). - `-x integrationTest` trims an expensive task irrelevant to this investigation. ## Interaction subtleties - **`--dry-run` dominates execution-side flags**: with `--dry-run`, `--rerun-tasks`/`--continue` have nothing to act on because no task executes. - **`--continue` + `--rerun-tasks`**: you force all tasks to run AND keep going on failure — maximal coverage of the failure surface in one run. - **`--offline` is resolution-only**: it never changes which tasks run or how failures are handled; it can still cause failure if the cache lacks an artifact, which `--continue` would then report alongside others. - **`-x` is applied before execution**, so it interacts with the dependency-pruning rule independently of the other flags. ## Why this matters for a senior Understanding the axes lets you build a precise, minimal command rather than flailing with `clean build` repeatedly. It also clarifies CI policy: which flags belong in pipelines (often `--continue` for full reporting) versus which are local-only diagnostics (`--rerun-tasks`, `--dry-run`).

  • If you add `--dry-run` to a command with `--rerun-tasks --continue`, what runs?
    Nothing executes. `--dry-run` only prints the task graph (all SKIPPED), so the execution-side flags have nothing to act on — dry-run effectively dominates them.
  • Which of these flags would you put in a CI verification stage, and which are local-only?
    `--continue` is a reasonable CI choice for full failure reporting. `--rerun-tasks` and `--dry-run` are local diagnostics; baking `--rerun-tasks` into CI defeats caching, and `--offline` in CI only works with a pre-seeded cache/mirror.
  • Why might `--offline` itself cause a failure that `--continue` then reports?
    If the local cache is missing a needed artifact, offline resolution fails. With `--continue`, that resolution failure is collected and reported alongside any task failures rather than aborting immediately.

saying these in an interview costs you the question

  • Claiming the flags conflict and can't be combined.
  • Putting `--rerun-tasks` in CI as a default (defeats incremental/cache).
  • Expecting tasks to execute under `--dry-run` when combined with `--rerun-tasks`.

context

resolving links…