Task Declaration & Registration
The ways a task comes into existence: lazy register versus eager create, the built-in task types Gradle ships, and plain ad-hoc tasks. Interviewers use this area to check whether you write builds that stay cheap to configure.
on this pageshowhide
explore
- register (Lazy) vs create (Eager)5 questions
- Configuration Avoidance API5 questions
- Locating Tasks: named & withType5 questions
- File Tasks: Copy, Sync, Delete5 questions
- Archive & Exec Tasks: Zip, Tar, Exec5 questions
- Ad-hoc & DefaultTask Tasks5 questions
- Build Init6 questions
questions
page 2 of 2A team's configuration phase is slow. They use tasks.getByName(), withType().all{}, and iterate tasks eagerly to configure them. How would you diagnose and fix this using lazy task-location APIs?
basics
~10 sThese eager accessors realize every referenced task during configuration, even unused ones. Replace getByName() with named(), withType().all{} with withType().configureEach{}, and remove eager iteration. Measure with a build scan or --profile before and after.
You're migrating an old build that uses tasks.create everywhere to tasks.register. What changes in behavior must you watch for, and why isn't it always a drop-in replacement?
basics
~20 screate returns a Task, register returns a TaskProvider — callers expecting a concrete Task break. Code that relied on the task existing/configured immediately (side effects, ordering, getByName) may now run later or not at all unless realized.
Explain how archive file naming and the archiveFile output are exposed as lazy Provider/Property types, and why wiring archiveFile downstream is better than hardcoding a path.
basics
~10 sArchive name parts (archiveBaseName, version, etc.) are Property objects and the resulting file is archiveFile, a Provider<RegularFile>. Wiring that provider into other tasks keeps the dependency lazy and lets Gradle track it correctly.
Why can running external processes break Gradle's configuration cache, and how do ExecOperations and an Exec task differ in this regard?
basics
~20 sRunning a process at configuration time isn't cacheable, so the configuration cache rejects it. Do process work at execution time — inside an Exec task's action, or via the injected ExecOperations service in a custom task — not in the configuration phase.
What does the `--incubating` flag do in `gradle init`, and when would you use it?
basics
~20 s--incubating makes gradle init opt into the latest, possibly-unstable APIs and conventions for the generated build—e.g. newer test-suite or version-catalog defaults—and unlocks incubating project types. It signals you accept that those features may still change.
In a large multi-project build, how would you drive down configuration time using the avoidance API and verify the improvement?
basics
~10 sReplace eager APIs (create/getByName/all/withType-closure) with register/named/configureEach across convention plugins, keep dependencies provider-based, then measure config time with build scans or --profile before/after.
showing 31–36 of 36