Command-Line Interface

In a multi-project build, subproject tasks can be executed with ":" separating subproject name and task name. The following are equivalent when run from the root project.

You can also run a task for all subprojects using the task name only. For example, this will run the "test" task for all subprojects when invoked from the root project directory.

When invoking Gradle from within a subproject, the project name should be omitted:

You can also specify multiple tasks. For example, the following will execute the test and deploy tasks in the order that they are listed on the command-line and will also execute the dependencies for each task.

You can exclude a task from being executed using the -x or --exclude-task command-line option and providing the name of the task to exclude.

You can see that the test task is not executed, even though it is a dependency of the dist task. The test task’s dependencies such as compileTest are not executed either. Those dependencies of test that are required by another task, such as compile, are still executed.

You can force Gradle to execute all tasks ignoring up-to-date checks using the --rerun-tasks option:

This will force test and all task dependencies of test to execute. It’s a little like running gradle clean test, but without the build’s generated output being deleted.

By default, Gradle will abort execution and fail the build as soon as any task fails. This allows the build to complete sooner, but hides other failures that would have occurred. In order to discover as many failures as possible in a single build execution, you can use the --continue option.

When executed with --continue, Gradle will execute every task to be executed where all of the dependencies for that task completed without failure, instead of stopping as soon as the first failure is encountered. Each of the encountered failures will be reported at the end of the build.

If a task fails, any subsequent tasks that were depending on it will not be executed. For example, tests will not run if there is a compilation failure in the code under test; because the test task will depend on the compilation task (either directly or indirectly).

When you specify tasks on the command-line, you don’t have to provide the full name of the task. You only need to provide enough of the task name to uniquely identify the task. For example, it’s likely gradle che is enough for Gradle to identify the check task.

You can also abbreviate each word in a camel case task name. For example, you can execute task compileTest by running gradle compTest or even gradle cT.

You can also use these abbreviations with the -x command-line option.

It is common in Gradle builds for the build task to designate assembling all outputs and running all checks.

It is common for applications to be run with the run task, which assembles the application and executes some script or binary.

It is common for all verification tasks, including tests and linting, to be executed using the check task.

You can delete the contents of the build directory using the clean task, though doing so will cause pre-computed outputs to be lost, causing significant additional build time for the subsequent task execution.

Running gradle projects gives you a list of the sub-projects of the selected project, displayed in a hierarchy.

You also get a project report within build scans. Learn more about creating build scans.

Running gradle tasks gives you a list of the main tasks of the selected project. This report shows the default tasks for the project, if any, and a description for each task.

By default, this report shows only those tasks which have been assigned to a task group. You can obtain more information in the task listing using the --all option.

If you need to be more precise, you can display only the tasks from a specific group using the --group option.

Running gradle help --task someTask gives you detailed information about a specific task.

This information includes the full task path, the task type, possible command line options and the description of the given task.

Build scans give a full, visual report of what dependencies exist on which configurations, transitive dependencies, and dependency version selection.

This will give you a link to a web-based report, where you can find dependency information like this.

Learn more in Inspecting Dependencies.

Running gradle dependencies gives you a list of the dependencies of the selected project, broken down by configuration. For each configuration, the direct and transitive dependencies of that configuration are shown in a tree. Below is an example of this report:

Concrete examples of build scripts and output available in the Inspecting Dependencies.

Running gradle buildEnvironment visualises the buildscript dependencies of the selected project, similarly to how gradle dependencies visualizes the dependencies of the software being built.

Running gradle dependencyInsight gives you an insight into a particular dependency (or dependencies) that match specified input.

Since a dependency report can get large, it can be useful to restrict the report to a particular configuration. This is achieved with the optional --configuration parameter:

Running gradle properties gives you a list of the properties of the selected project.

You can get a hierarchical view of elements for software model projects using the model task:

Learn more about the model report in the software model documentation.

You can manage the Gradle Daemon through the following command line options.

You can customize the verbosity of Gradle logging with the following options, ordered from least verbose to most verbose. Learn more in the logging documentation.

Lifecycle is the default log level.

You can control the use of rich output (colors and font variants) by specifying the "console" mode in the following ways:

By default, Gradle won’t display all warnings (e.g. deprecation warnings). Instead, Gradle will collect them and render a summary at the end of the build like:

You can control the verbosity of warnings on the console with the following options:

Gradle’s rich console displays extra information while builds are running.

Features:

Use the built-in gradle init task to create a new Gradle builds, with new or existing projects.

Most of the time you’ll want to specify a project type. Available types include basic (default), java-library, java-application, and more. See init plugin documentation for details.

The built-in gradle wrapper task generates a script, gradlew, that invokes a declared version of Gradle, downloading it beforehand if necessary.

You can also specify --distribution-type=(bin|all), --gradle-distribution-url, --gradle-distribution-sha256-sum in addition to --gradle-version. Full details on how to use these options are documented in the Gradle wrapper section.

If Gradle is attached to an interactive input source, such as a terminal, the continuous build can be exited by pressing CTRL-D (On Microsoft Windows, it is required to also press ENTER or RETURN after CTRL-D). If Gradle is not attached to an interactive input source (e.g. is running as part of a script), the build process must be terminated (e.g. using the kill command or similar). If the build is being executed via the Tooling API, the build can be cancelled using the Tooling API’s cancellation mechanism.

There are several issues to be aware with the current implementation of continuous build. These are likely to be addressed in future Gradle releases.