The Gradle Console - Gradle User Guide Version 4.4

# Chapter 5. The Gradle Console

## 5.1. Overview

Nearly every Gradle user will experience the command-line interface at some point. Gradle’s console output is optimized for rendering performance and usability, showing only relevant information and providing visually appealing feedback.

Figure 5.1. The Gradle command-line in action

## 5.2. Command-line feedback

Gradle displays information while the build is running so you can concentrate on the most important items of interest. Each of the sections of Gradle’s console output help answer specific questions.

- Is there anything I should know about my build right now e.g. tests have failed and emitted warnings?

- When will my build finish?

- What is Gradle doing right now?

- Are there other interesting outcomes e.g. tasks that have been skipped or were up-to-date?

### 5.2.1. Build output

Output from build script log messages, tasks, forked processes, test output and compile warnings is displayed above the build progress bar.

Figure 5.2. Build output portion of the Gradle command-line

Starting with Gradle 4.0, the volume of command-line console output has been reduced. The start and end of each task is not displayed anymore or the outcome of the task (e.g. `UP-TO-DATE`). The task’s name is only displayed if some output is emitted during task execution. Gradle also groups output originating from a specific context together, e.g. all warnings from a compilation task, test execution or forked processes. Grouped output is especially useful for parallel task execution, as it prevents interleaved messages that do not clearly indicate their origin (see Section 26.8, “Parallel project execution”).

Grouped console output and reduced console output only occurs with interactive and rich console command-lines. Continuous integration servers and builds using `--console=plain` will see console output similar to pre-Gradle 4.0. You can also set this option via `org.gradle.console` property, see Section 12.1, “Configuring the build environment via gradle.properties”.

The following console output shows grouped output for the configuration phase and the task `:compileJava`:

    > Configure project ':library'
    Configuring project version for project ':library'

    > Configure project ':consumer'
    Configuring project version for project ':consumer'

    > Task :compileJava
    Note: Some input files use unchecked or unsafe operations.
    Note: Recompile with -Xlint:unchecked for details.

Gradle does not wait until a unit of work is fully completed before displaying its output. Gradle flushes output to the console after a short amount of time to ensure that relevant information is made available as soon as possible. When building in parallel, the output of long running tasks can be broken up by other tasks. Each block of console output will clearly indicate which task it belongs to.

    > Task :compileJava
    Note: Some input files use unchecked or unsafe operations.
    Note: Recompile with -Xlint:unchecked for details.

    > Task :generateCode
    Generating JAXB classed from XSD files.

    > Task :compileJava
    Note: Some input files use or override a deprecated API.
    Note: Recompile with -Xlint:deprecation for details.

### 5.2.2. Build progress bar

The build progress bar gives you a very fast way of knowing if the build will be finished soon. As the build performs work, the progress bar will fill from left to right. At any given time, the build progress bar also renders the current phase of the build lifecycle (see Section 22.1, “Build phases”) and the overall time spent during the build.

Figure 5.3. Build progress bar portion of the Gradle command-line

The following examples shows the progress bar during the initialization, configuration and execution phase of the build lifecycle:

    <-------------> 0% INITIALIZING [2s]
    <==-----------> 25% CONFIGURING [4s]
    <=========----> 64% EXECUTING [17s]

### 5.2.3. Work in-progress display

Gradle provides a fined-grained view of the actual work being performed directly underneath the The build progress bar. Each line represents a thread or process that can perform work in parallel—​resolving dependencies, executing a task and running tests. If an available worker is not being used then it is marked with `IDLE`. The number of available workers defaults to the number of processors on the machine executing the build.

Figure 5.4. Work in-progress portion of the Gradle command-line

Parallel test execution is only displayed for JVM-based tests supported by Gradle core e.g. JUnit and TestNG. Future versions of Gradle might support other testing tools and frameworks.

The following portion of the console output shows the work in-progress display with 8 concurrent workers:

    <==========---> 77% EXECUTING [10s]
    > :codeQuality:classpathManifest > Resolve dependencies :codeQuality:runtimeClasspath
    > :ivy:classpathManifest > Resolve dependencies :ivy:runtimeClasspath
    > IDLE
    > :antlr:classpathManifest > Resolve dependencies :antlr:runtimeClasspath
    > :scala:compileJava > Resolve dependencies :scala:compileClasspath
    > :buildInit:classpathManifest > Resolve dependencies :buildInit:runtimeClasspath
    > :jacoco:classpathManifest > Resolve dependencies :jacoco:runtimeClasspath
    > IDLE

### 5.2.4. Build result

At the end of the build, Gradle will display the result of the build (successful or failed) and the number of tasks that performed work and avoided work. The build result also displays the overall elapsed time it took to execute the build. The number of tasks that performed work provides an indication of how out-of-date or busy the build was.

Figure 5.5. Build progress bar portion of the Gradle command-line

The following build result represents a successful build and the amount of tasks including their statuses:

    BUILD SUCCESSFUL in 2m 10s
    411 actionable tasks: 381 executed, 30 up-to-date

"Actionable" tasks are tasks with at least one action. Lifecycle tasks like `build` (also called aggregation tasks) do not declare any actions and are therefore not actionable.

## 5.3. Look & feel in non-interactive environments

By default, Gradle tries to enable rich console output by detecting the type of console the build is running from. This enables color and additional console output formatting. Non-interactive environments fall back to using plain console output. The plain output format does not support grouping of output. Tasks and outcomes are always printed to be consistent with Gradle 3.x versions.

Gradle builds executed from an IDE (e.g. Buildship and IntelliJ) or Continuous Integration products (e.g. Jenkins and TeamCity) use plain console output by default.

The following output demonstrates the use of a plain console:

    :compileJava
    Note: Some input files use unchecked or unsafe operations.
    Note: Recompile with -Xlint:unchecked for details.
    :processResources
    :classes
    :jar
    :assemble
    :compileTestJava NO-SOURCE
    :processTestResources NO-SOURCE
    :testClasses UP-TO-DATE
    :test NO-SOURCE
    :check UP-TO-DATE
    :build

    BUILD SUCCESSFUL in 6s
    11 actionable tasks: 6 executed, 5 up-to-date