skip to content

What are the practical limitations of continuous build, and which kinds of tasks is it well- or poorly-suited for?

level: middleimportance: should knowfreq 26%

answer

  1. re-runs, not hot-reload
  2. blocking tasks stall the loop
  3. build-script edits → restart
  4. great for test/compile/codegen
  5. needs daemon + working FS watch

basics

~20 s

Continuous build re-runs the build, it does not hot-reload a running app. It suits finite tasks (compile, test, codegen) for fast feedback. It is poor for tasks that block forever (servers) and does not reliably react to build-script edits.

solid answer

~50 s

Continuous build is best for **finite, fast-feedback** tasks — `compileJava`, `test`, code generation, doc builds — where each input edit re-runs the graph and you see results immediately, especially when paired with incremental tasks and the build cache. Its limits: (1) it **re-runs the build**, it does not hot-swap classes into a live process, so 'auto-restart my server' needs extra tooling, not just `-t`; (2) a task that **blocks forever** (a long-running server/`run`) holds the loop, so the next change can't trigger until it stops; (3) **build-logic changes** (`build.gradle(.kts)`, plugins) are not watched the way source inputs are — you usually restart for those; (4) it watches only **declared inputs**, so under-declared tasks won't trigger; (5) it needs a persistent **daemon** and working **file-system watching**, which can be unreliable on some network/container mounts. For application live-reload you generally combine it with a framework's own dev-mode or a plugin rather than relying on continuous build alone.

go deeper

for a junior

Know it suits test/compile loops and that it re-runs rather than hot-reloads.

for a middle

Enumerate the limits: blocking tasks, build-script edits, declared-inputs-only, daemon/watch requirements.

for a senior

Recommend the right tool per scenario (continuous build vs. framework dev-mode/live-reload) and reason about iteration cost with caching.

for a principal

Define team guidance on inner-loop tooling: when continuous build is the standard vs. dedicated dev-servers, and the infra constraints in containers/CI.

## What it's great at - **Test loops:** `gradle -t test` re-runs tests on each edit; with incremental compile + the build cache, only affected work re-runs. - **Code generation / doc builds:** regenerate sources or docs whenever the source-of-truth file changes. - **Compile-only feedback:** `gradle -t compileJava` for fast syntax/type feedback. ## Hard limits to call out ### 1. It re-runs, it does not hot-reload Continuous build re-executes the task graph. It does **not** inject new bytecode into an already-running JVM. So 'continuously run my web app and reflect changes' is not something `-t :run` gives you on its own — the run task would either finish (and restart on change) or block. ### 2. Blocking tasks stall the loop If the requested task **never returns** (a server that runs until killed), Gradle stays inside that task; changes detected meanwhile can't start a new iteration until the current one ends. Continuous build is happiest with tasks that **complete**. ### 3. Build-script / plugin changes Editing `build.gradle.kts`, `settings.gradle.kts`, or plugin code is **not** treated like a watched source input. Practically, you stop and restart the continuous build after build-logic edits. ### 4. Only declared inputs trigger The watched set is the union of declared task inputs. Under-declared inputs simply won't fire — see input-correctness. ### 5. Infrastructure requirements Needs a persistent **daemon** and **VFS file-system watching**; on flaky network/container file systems, watching may miss events (mitigate with `--no-watch-fs` and re-scan, accepting slower iterations). ## Putting it together ```bash # Good fit gradle -t test gradle -t :docs:asciidoctor # Poor fit on its own — prefer the framework's dev mode # (e.g. a web app live-reload) instead of: gradle -t :app:bootRun ``` The interview signal is recognizing continuous build as a **build-loop** accelerator, not an application live-reload mechanism, and knowing exactly where each boundary lies.

  • Why doesn't `gradle -t :app:run` give you live application reload?
    The run task either blocks (holding the loop so changes can't re-trigger) or completes and is restarted as a whole process — continuous build re-executes tasks, it doesn't hot-swap code into a live JVM. Live reload needs framework dev-mode or a dedicated plugin.
  • What should you do after editing build.gradle.kts during a continuous build?
    Stop and restart the continuous build; build-logic changes aren't watched like source inputs and won't be picked up reliably mid-loop.

saying these in an interview costs you the question

  • Claiming `-t` hot-reloads a running server with no extra tooling.
  • Assuming build-script edits are picked up automatically mid-loop.
  • Saying it speeds up an individual task — it just re-triggers the build; speed comes from incrementality/caching.

context

resolving links…