skip to content

When triaging a CI build failure you can't reproduce locally, would you reach for --info/--debug or a build scan, and why?

level: seniorimportance: should knowfreq 45%

answer

  1. scan = structured shareable report
  2. info = low-noise local triage
  3. debug = last-resort firehose
  4. scan best for non-reproducible
  5. flags compose

basics

~10 s

Prefer a build scan (--scan): it captures a complete, shareable web report of the failure. Use --info for quick local context and --debug only as a noisy last resort.

solid answer

~40 s

For a hard-to-reproduce CI failure, a **build scan** (`--scan`) is usually the best tool: it uploads a structured, web-hosted report — timeline, every task's inputs/outputs and outcome, dependency resolution, deprecations, environment, and the full failure cause chain — to a shareable URL the whole team can inspect. That beats scrolling raw console logs. `--info` is the right call for fast local triage: it explains up-to-date/cache decisions and adds context without overwhelming you. `--debug` is a last resort — it's so verbose it's hard to read, bloats CI logs, and can leak internal detail. A pragmatic policy: enable build scans on CI (or on failure), have engineers run `--info` locally first, and reserve `--debug`/`--full-stacktrace` for cases the scan and info don't resolve. The flags are also combinable: `--info --stacktrace --scan` gathers everything in one run.

code

bash · 8 lines
bash
# CI triage: capture everything once, get a shareable URL
./gradlew build --info --stacktrace --scan

# Local first pass
./gradlew build --info

# Only if info is insufficient
./gradlew build --debug --full-stacktrace

go deeper

for a junior

Know --info gives more detail and a scan produces a shareable report; details optional.

for a middle

Choose --info for quick triage and --scan for sharing; know --debug is the noisy last resort.

for a senior

Articulate the cost/benefit of each, what a scan captures over logs, and when to escalate; combine flags in one run.

for a principal

Define org policy: scans always-on (or on-failure) in CI, --info as the local standard, --debug discouraged in tickets; justify on log hygiene, shareability, and diagnostic completeness.

## The triage toolbox When a build misbehaves you have layered diagnostics, each with a cost/benefit: ### `--info` (-i) Raises the log threshold to INFO. You get up-to-date reasons, build-cache hit/miss notes, and dependency-resolution detail. **Low noise, high signal** for everyday "why did this run / get skipped?" questions. The first thing to try locally. ### `--debug` (-d) Raises to DEBUG — everything, including Gradle internals. **Very high noise.** It can answer questions `--info` can't, but the volume makes it hard to read, slows log rendering, bloats CI artifacts, and may surface internal paths. A last resort, not a default. ### Build scans (`--scan`) Publishes a **structured, web-hosted report** rather than text. It captures: - a **timeline** of tasks (durations, parallelism) - each task's **inputs, outputs, and outcome** (executed / up-to-date / from-cache) - **dependency resolution** and version selection - **deprecation warnings** and the **environment** (JVM, OS, Gradle version) - the **full failure cause chain** Because it's a shareable URL, it shines for **non-reproducible** failures: the engineer who hit it can send the scan to a teammate, and CI scans let you compare a failing run against a passing one. It captures far more context than any single console flag, and you don't have to know in advance which detail you'll need. ## Choosing ```text Can't reproduce / need to share / want structured insight -> --scan Quick local 'why ran/skipped/cached?' -> --info --info wasn't enough and you suspect internals -> --debug / --full-stacktrace ``` They compose — one run can do all of it: ```bash ./gradlew build --info --stacktrace --scan ``` ## Policy view At team scale: wire build scans into CI (publish always, or on failure), standardize on `--info` for local triage, and discourage pasting `--debug` dumps into tickets (noise + potential internal-detail leakage). This gives consistent, shareable diagnostics and keeps CI logs clean.

  • Why is --debug a poor default for CI logs?
    It's extremely verbose (including Gradle internals), which bloats and slows logs, makes them hard to read, and can surface internal paths — so it adds cost without proportional signal as a default.
  • What can a build scan reveal that raising the log level cannot?
    A structured, shareable timeline with per-task inputs/outputs/outcomes, dependency resolution, deprecations, environment, and the full cause chain — plus the ability to compare runs — rather than unstructured text you must grep.
  • Can you gather scan + info + trace in a single invocation?
    Yes. The flags are orthogonal: `./gradlew build --info --stacktrace --scan` produces verbose logs, the exception chain, and a shareable report in one run.

--info is asking a colleague 'what were you doing when it broke?'; --debug is reading their entire stream of consciousness; a build scan is a flight recorder — a complete, replayable black-box you can hand to anyone.

saying these in an interview costs you the question

  • Defaulting to --debug for everything 'to be safe' — it's noise that hides signal.
  • Believing a build scan is just the console log saved to a file — it's a structured, far richer report.
  • Assuming the flags are mutually exclusive — they compose.

context

resolving links…