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

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

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

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'>

image::task-dag-examples.png[]

[[build_lifecycle_events]]
Both plugins and build scripts contribute to the task graph via the <<tutorial_using_tasks.adoc#sec:task_dependencies,task dependency mechanism>> and <<incremental_build.adoc#sec:task_inputs_outputs,annotated inputs/outputs>>.

[[sec:build_phases]]
== Build Phases

A Gradle build has three distinct phases.

image::author-gradle-1.png[]

Gradle runs these phases in order:

                "Declare the task as untracked by using Task.doNotTrackState(). " +
                new DocumentationRegistry().getDocumentationRecommendationFor("information", "incremental_build", "sec:disable-state-tracking")
            )
            failure.assertHasCause("java.nio.file.AccessDeniedException: ${dir}")
        } finally {
            dir.permissions = oldPermissions
        }
    }

[[sec:continuous_build_untracked]]
=== Inputs of untracked tasks
Changes to the inputs of <<incremental_build.adoc#sec:disable-state-tracking,untracked tasks>> or tasks that have no outputs may not trigger a build.

[[sec:continuous_build_project_dir]]
=== Changes to files outside of project directories