Most tasks that are used to build Gradle support the configuration cache, but some don't. For example, building the documentation currently requires you to disable the configuration cache.

To disable the configuration cache, run the build with `--no-configuration-cache`.

Tasks known to have problems are listed in the build logic. You can find this list at:

See [Gradle runtimes](runtimes.md) for a list of these runtimes and more details.

## Build state model

As Gradle executes, it acts on various pieces of the build definition, such as each project in the build.
Gradle tracks the state of each piece and transitions each piece through its lifecycle as the build runs.

    /* the implementation class to collect information from task execution result */
    klass: Class<T>,
    /* which tasks we need to monitor? For example, cache-miss-monitor monitors `AbstractCompile` tasks */
    taskFilter: (Task) -> Boolean,
    /* pass the collected information in build-logic and main build to build scan */
    buildScanAction: BuildScanConfiguration.(Any, Any) -> Unit

      - name: Setup Gradle
        uses: gradle/actions/setup-gradle@v3
        with:
          cache-read-only: ${{ github.ref != 'refs/heads/master' }}

# Build state model

The Gradle daemon tracks state for various elements. These are arranged in a hierarchy:

```mermaid
  graph TD

  process["build process"]
  
  session["build session"]
  process --> session
  
  build_tree["build tree"]
  session --> build_tree
  
  build1["root build"]
  build_tree --> build1
  
  project1["root project"]
  build1 --> project1
  
  project2["project"]
  build1 --> project2