With configuration on demand enabled, how does Gradle decide which projects to configure for a given set of requested tasks?

## The reachability set Under configuration on demand, Gradle starts from the requested tasks and configures **only** the projects it can reach through *declared* relationships: 1. **Root project** — always configured, because root scripts often define shared conventions. 2. **Owning projects of requested tasks** — `gradle :a:build :b:test` configures `:a` and `:b`. 3. **Project dependencies** — if `:a` declares `implementation(project(":lib"))`, then `:lib` is configured; if `:lib` in turn depends on `:base`, `:base` is configured too. This is a transitive walk over the project dependency graph. 4. **Explicit cross-project task dependencies** — `tasks.named("x") { dependsOn(":other:y") }` forces `:other` to be configured so task `y` exists. ## What is NOT pulled in - Projects you didn't request and that nothing in the reachable set depends on. - Side effects from **cross-project configuration blocks**: `allprojects {}`, `subprojects {}`, or a project that imperatively reaches into another (`project(":other").extensions…`, `rootProject.subprojects.forEach { … }`). Because the *source* project of that side effect may itself never be configured, the mutation never happens. ## Worked example ```kotlin // settings.gradle.kts include(":app", ":core", ":util", ":reports") // app/build.gradle.kts dependencies { implementation(project(":core")) } // core/build.gradle.kts dependencies { implementation(project(":util")) } ``` Running `gradle :app:assemble --configure-on-demand` configures: **root, :app, :core, :util**. `:reports` is **skipped** — nothing reachable from `:app` references it. If `:reports` had a `subprojects {}` block in root that other projects relied on, you'd have a problem only if that wiring lived in an unconfigured project; root itself is always configured, so root-level `subprojects {}` is a particularly dangerous pattern here. ## Why cross-project config breaks it The whole optimization assumes a project's contribution to the graph is fully captured by its **own** script plus its **declared** dependencies. Imperative cross-project configuration violates that assumption: project A's script changing project B means B's final state depends on whether A was configured — which configure-on-demand doesn't guarantee. This is precisely why Gradle pushed toward **convention plugins** and isolated project models (and later **Project Isolation**), where each project's configuration is self-contained. ## Verifying Use `--info` and inspect which projects Gradle reports configuring; compare against your expectation. A surprising 'all projects configured' usually means an `allprojects/subprojects` block (often in root) is forcing eager evaluation.