then:
        succeeds("foo")
        file('build/foo/foo').text == 'bar'

        when:
        file('foo').text = 'baz'

        then:
        buildTriggeredAndSucceeded()
        file('build/foo/foo').text == 'baz'
    }

    @ToBeFixedForConfigurationCache(skip = INVESTIGATE)
    def "can change cache configurations in between builds in a session"() {
        executer.requireOwnGradleUserHomeDir()

[[sub:ephemeral-ci-cache]]
== Dealing with ephemeral builds

It's a common practice to run builds in ephemeral containers.
A container is typically spawned to only execute a single build before it is destroyed.
This can become a practical problem when a build depends on a lot of dependencies which each container has to re-download.

==== buildSrc can now see included builds from the root

Previously, `buildSrc` was built in such a way that included builds were ignored from the root build.

Since Gradle 6.7, `buildSrc` can see any included build from the root build.
This may cause dependencies to be substituted from an included build in `buildSrc`.
This may also change the order in which some builds are executed if an included build is needed by `buildSrc`.

Android developers should watch a presentation by the Android SDK Tools team about link:https://youtu.be/7ll-rkLCtyk[Speeding Up Your Android Gradle Builds].
Many tips are also covered in the Android Studio user guide link:https://developer.android.com/studio/build/optimize-your-build.html[on optimizing build speed].

[[sec:troubleshooting_build_logic]]
== Debugging build logic

=== Kotlin DSL build structure samples

Depending on your build structure you might be interested in the following user manual chapters:

* The <<writing_build_scripts#writing_build_scripts,Writing Build Scripts>> chapter demonstrates the use of `apply(from = "")` to modularize build scripts.
* The <<multi_project_builds#multi_project_builds,Multi-project Builds>> chapter demonstrates various multi-project build structures.

Properties in a build script can easily become a maintenance headache and convolute the build script logic.
The `gradle.properties` helps with keeping properties separate from the build script and should be explored as viable option.
It's a good location for placing <<build_environment.adoc#sec:gradle_configuration_properties,properties that control the build environment>>.

                                performanceResults.buildResult(displayInfo).add(operation);
                                builds.add(displayInfo);
                            }
                        }
                    }
                    return new CrossBuildPerformanceTestHistory(experiment, ImmutableList.copyOf(builds), results);
                }
            }
        });
    }

import java.util.List;
import java.util.Map;

/**
 * Executes a Gradle build, allowing inspection of the outcome.
 * <p>
 * A Gradle runner can be used to functionally test build logic, by executing a contrived build.
 * Assertions can then be made on the outcome of the build, such as the state of files created by the build,
 * or what tasks were actually executed during the build.
 * <p>
 * A runner can be created via the {@link #create()} method.

        buildSrcOps[0].displayName == "Build buildSrc"
        buildSrcOps[0].details.buildPath == ":buildB"

        def loadOps = operations.all(LoadBuildBuildOperationType)
        loadOps.size() == 3
        loadOps[0].displayName == "Load build"
        loadOps[0].details.buildPath == ":"
        loadOps[0].parentId == root.id

        loadOps[1].displayName == "Load build (:buildB)"
        loadOps[1].details.buildPath == ":buildB"

        given:
        List<BuildTestFile> builds = (1..3).collect { idx ->
            def lib = mavenRepo.module("org.test.foo", "build${idx}").publish()
            def build = new BuildTestFile(file("build${idx}"), "build${idx}")
            setupBuild(build)
            build.with {
                def toBeTransformed = file(build.rootProjectName + ".jar")
                toBeTransformed.text = '1234'