skip to content

How do you discover the exact name and command-line options of a task you want to run, without leaving the terminal?

level: juniorimportance: should knowfreq 40%

answer

  1. tasks = discovery
  2. help --task = detail
  3. shows path/type/options
  4. help is the default task
  5. @Option flags surface here

basics

~10 s

Run gradle tasks to list available tasks, then gradle help --task <name> to see that task's full path, type, description, and any CLI options.

solid answer

~30 s

Start with `gradle tasks` (add `--all` to include ungrouped tasks) to find the task name. Then `gradle help --task test` prints a detailed description: the task's fully-qualified path(s) across projects, its type/class, a description, and the **task-specific command-line options** it accepts (for example `--tests` on `Test`, or `--rerun`). This is the fastest way to learn that, say, `test` supports `--tests com.acme.MyTest` without consulting docs. `help` is itself the default task, so a bare `gradle` runs it. Combined, `tasks` (discovery) and `help --task` (detail) let you explore any project's build surface from the CLI alone.

code

bash · 4 lines
bash
./gradlew tasks --all
./gradlew help --task test
# Now use a discovered option:
./gradlew test --tests 'com.acme.OrderServiceTest'

go deeper

for a junior

Know the two commands (tasks, help --task) and that help --task shows options.

for a middle

Mention --all, that options come from @Option, and that help is the default task.

for a senior

Connect it to multi-project paths and discovering task-specific flags (e.g. --tests on Test) as a docs-free workflow.

for a principal

Encourage descriptive task descriptions/groups and @Option declarations on custom tasks so the team's build is self-documenting via these report tasks.

## Two-step discovery Gradle gives you everything you need to explore a build from the terminal. ### Step 1 — `tasks` (what can I run?) ```bash ./gradlew tasks # grouped, user-facing tasks with descriptions ./gradlew tasks --all # also ungrouped tasks and rule-based tasks ``` The output groups tasks (Build, Verification, Help, …) and prints each task's one-line description. `--all` is essential when the task you want isn't in a group. ### Step 2 — `help --task <name>` (tell me about this task) ```bash ./gradlew help --task test ``` This prints: - the task's **fully-qualified path(s)** — e.g. `:app:test`, `:lib:test` — so you know where it lives in a multi-project build - the task **type / implementing class** (e.g. `org.gradle.api.tasks.testing.Test`) - the **description** - the **command-line options** the task declares, with their descriptions Those CLI options are task-specific flags declared via `@Option`. For the `Test` task you'll see things like `--tests <pattern>` (filter test classes/methods) and `--rerun` (ignore up-to-date and run anyway). Discovering them via `help --task` saves a trip to the documentation. ## help is the default task Running `gradle` with no arguments runs `help`, which prints top-level guidance (how to list tasks, where to get more help). So the entry point to all of this is just typing `gradle`. ## Putting it together ```bash ./gradlew tasks --all # discover the name ./gradlew help --task test # learn its path + options ./gradlew test --tests 'com.acme.*' # use what you learned ``` This discover-then-detail loop is the CLI-native alternative to reading build scripts or docs.

  • What kinds of information does `help --task` print?
    The task's fully-qualified path(s) across projects, its implementing type/class, its description, and the task-specific command-line options it declares (with descriptions).
  • What runs if you invoke `gradle` with no task at all?
    The `help` task runs — it's the default — printing top-level guidance such as how to list tasks and get more help.

saying these in an interview costs you the question

  • Assuming you must read the build script to find a task's CLI options — help --task lists them.
  • Forgetting --all and concluding a task doesn't exist when it's just ungrouped.
  • Confusing `gradle help` (general) with `gradle help --task <name>` (specific).

context

resolving links…