skip to content

How do you set the group, description, and dependsOn of an ad-hoc task, and what does each one do?

level: middleimportance: should knowfreq 55%

answer

  1. group = category in `tasks`
  2. description = one-line help
  3. dependsOn = prerequisite ordering
  4. ungrouped hidden without --all
  5. prefer output→input wiring over dependsOn for data

basics

~10 s

Inside the register block set group (the category in gradle tasks), description (the help text), and call dependsOn(...) to declare tasks that must run before this one. All three are properties on every task.

solid answer

~40 s

These three are standard properties available on any task, ad-hoc included. **`group`** is a string category — tasks sharing a group appear together under `./gradlew tasks` (e.g. "build", "verification", or a custom name); tasks with no group are hidden unless you pass `--all`. **`description`** is the one-line help text shown beside the task name in that listing. **`dependsOn(...)`** declares execution-order dependencies: before this task runs, every task it depends on must run first. You can pass task names (strings), `TaskProvider`s, or other objects. Setting these makes an ad-hoc task discoverable and properly ordered. Note `dependsOn` only guarantees ordering of *whole tasks* — for finer wiring (an input file produced by another task) you prefer wiring outputs to inputs via providers, which adds an implicit dependency automatically.

code

kotlin · 6 lines
kotlin
tasks.register("deployDocs") {
    group = "documentation"
    description = "Publishes the generated docs"
    dependsOn("generateDocs")
    doLast { println("deploying") }
}

go deeper

for a junior

Set group/description and call dependsOn with a task name.

for a middle

Explain visibility rules of group, accepted dependsOn argument types, and that dependsOn is whole-task ordering.

for a senior

Contrast dependsOn with implicit dependencies from provider wiring and with mustRunAfter/shouldRunAfter for ordering-only constraints.

for a principal

Establish conventions: grouped/described tasks for discoverability, provider wiring over string dependsOn to keep the task graph correct and config-cache safe.

## The three properties ```kotlin tasks.register("deployDocs") { group = "documentation" description = "Publishes the generated docs" dependsOn("generateDocs") doLast { /* upload */ } } ``` ### group A free-form category string. `./gradlew tasks` groups tasks by it and only shows grouped tasks by default; ungrouped ("other") tasks need `./gradlew tasks --all`. Conventionally you reuse standard groups ("build", "verification", "documentation", "help") or define your own. ### description The single-line summary printed next to the task in `tasks` output and in IDE task views. Keep it short and imperative. ### dependsOn Declares that other tasks are **prerequisites**: Gradle adds edges to the task graph so dependencies run first. Accepts: - task names as `String` (`dependsOn("compileJava")`), - `TaskProvider`/`Task` references (`dependsOn(myTask)`), - collections, or a `Provider` that yields tasks. `dependsOn` controls **ordering of entire tasks**, not data flow. If task B consumes a file produced by task A, the idiomatic approach is to wire A's output provider into B's input property; Gradle then infers the dependency automatically (an *implicit task dependency*) and you don't need an explicit `dependsOn`. ## mustRunAfter / shouldRunAfter For pure ordering without making one a prerequisite of the other, use `mustRunAfter`/`shouldRunAfter` instead of `dependsOn` — those constrain order only when both tasks are already scheduled. ## Why it matters Ungrouped, undescribed ad-hoc tasks clutter the build and are hard to discover. Setting `group`/`description` is the cheap polish that makes a build self-documenting; correct `dependsOn` (or provider wiring) prevents "works on my machine" ordering bugs.

  • Why might a task not show up in ./gradlew tasks?
    It has no group, so it's hidden in the 'other' category; run ./gradlew tasks --all to see it.
  • When should you avoid dependsOn in favor of provider wiring?
    When one task consumes another's output file — wire the output provider into the input property so Gradle infers the dependency and tracks the data correctly.
  • What's the difference between dependsOn and mustRunAfter?
    dependsOn forces the other task to run; mustRunAfter only constrains order when both tasks are already in the build.

saying these in an interview costs you the question

  • Using dependsOn to pass data between tasks instead of wiring output→input providers
  • Thinking mustRunAfter pulls a task into the build (it doesn't)

context

resolving links…