.Ad-hoc task
====
include::sample[dir="snippets/tasks/incrementalBuild-customTaskClass/kotlin",files="build.gradle.kts[tags=ad-hoc-task]"]
include::sample[dir="snippets/tasks/incrementalBuild-customTaskClass/groovy",files="build.gradle[tags=ad-hoc-task]"]

.Output of **`gradle processTemplatesAdHoc`**
----
> gradle processTemplatesAdHoc
include::{snippetsPath}/tasks/incrementalBuild-customTaskClass/tests/incrementalAdHocTask.out[]
----
====

        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.

----
=====
====

For more information, see link:{userManualPath}/more_about_tasks.html[Authoring Tasks reference chapter].

        "Declare the task as untracked by using Task.doNotTrackState(). " +
        new DocumentationRegistry().getDocumentationRecommendationFor("information", "incremental_build", "sec:disable-state-tracking")

    void expectUnreadableCopyDestinationFailure() {
        failure.assertHasDocumentedCause(COPY_UNREADABLE_DESTINATION_FAILURE)
    }

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.

     *     <li>a Java lambda was used as an input,</li>
     *     <li>an input is not tracked.</li>
     * </ul>
     *
     * @see <a href="https://docs.gradle.org/current/userguide/incremental_build.html#sec:how_does_it_work">How fingerprinting works</a>
     */
    NON_CACHEABLE_INPUTS

 * 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

 *     Normalization annotations such as {@link org.gradle.api.tasks.PathSensitive} or {@link org.gradle.api.tasks.Classpath} can be used as well.
 *     See the <a href="https://docs.gradle.org/current/userguide/incremental_build.html#table:incremental_build_annotations">table of incremental build property type annotations</a> for all annotations which can be used.
 *     Example:
 * </p>
 * <pre class='autoTested'>

[[filter_runtime_classpath]]
===== Filtering runtime classpaths

For a runtime classpath it is possible to provide better insights to Gradle which files are essential to the input by <<incremental_build.adoc#sec:configure_input_normalization,configuring input normalization>>.