new AbstractPluginValidationIntegrationSpec.DocumentedProblem(message, ERROR, id, section)
    }

    static <T extends ValidationMessageDisplayConfiguration> AbstractPluginValidationIntegrationSpec.DocumentedProblem warning(T message, String id = "incremental_build", String section = "") {

A first feature using the build cache is _task output caching_.
Essentially, task output caching leverages the same intelligence as <<incremental_build#incremental_build,up-to-date checks>> that Gradle uses to avoid work when a previous local build has already produced a set of task outputs.

CI already built this commit -- why should you re-do that work?

=== Switching branches

During local development, it is not uncommon to switch branches several times per day.
This defeats <<incremental_build.adoc#incremental_build,incremental build>> (i.e., `UP-TO-DATE` checks), but this issue is mitigated via use of the local build cache.
You might run a build on Branch A, which will populate the local cache.

 * a {@code validatePlugins} task, though if you cannot use this plugin then you need to register the task yourself.
 *
 * See the user guide for more information on
 * <a href="https://docs.gradle.org/current/userguide/incremental_build.html" target="_top">incremental build</a> and
 * <a href="https://docs.gradle.org/current/userguide/build_cache.html#sec:task_output_caching" target="_top">caching task outputs</a>.
 *
 * @since 6.0
 */
@CacheableTask

            this.config = config
            this.message = config.render()
            this.severity = severity
            this.id = id
            this.section = section
            this.defaultDocLink = (id == "incremental_build") && (section == "")
        }

└── subproject-b
    └── build.gradle
----
=====
====

== Avoid overlapping task outputs

Tasks should define inputs and outputs to get the performance benefits of <<incremental_build.adoc#incremental_build,incremental build functionality>>.
When declaring the outputs of a task, make sure that the directory for writing outputs is unique among all the tasks in your project.

====

The above example demonstrates the basic syntax and also highlights two major limitations of using the `copy()` method:

1. The `copy()` method is not <<incremental_build.adoc#incremental_build,incremental>>.
The example's `copyMethod` task will _always_ execute because it has no information about what files make up the task's inputs.
You have to define the task inputs and outputs manually.

Note that <<incremental_build.adoc#incremental_build,command line order safety>> relies on tasks properly declaring what they create, consume, or remove.

[[sec:excluding_tasks_from_the_command_line]]
=== Excluding tasks from execution

====

Writing and using <<more_about_tasks.adoc#sec:task_groups,custom task types>> is recommended when developing plugins as it automatically benefits from <<incremental_build.adoc#incremental_build,incremental builds>>.

                <li><a href="../userguide/gradle_daemon.html">Gradle Daemon</a></li>
                <li><a href="../userguide/file_system_watching.html">File System Watching</a></li>
                <li><a href="../userguide/incremental_build.html">Incremental Build</a></li>
                <li><a class="nav-dropdown" data-toggle="collapse" href="#build-cache" aria-expanded="false" aria-controls="optimizing-build-performance">Using the Build Cache</a>