When trying to use the gradle configuration cache, depending on the plugins applied and tasks configured various configuration cache problems will prevent builds from succeeding.

There are a few main issues that are in this project, listed below. Most of these were captured by taking the existing functional tests and adding --configuration-cache to the build arguments.

A set of issues related to calling project at task action time

- Task `:buildImage` of type `com.bmuschko.gradle.docker.tasks.image.DockerBuildImage`: invocation of 'Task.project' at execution time is unsupported.
  See https://docs.gradle.org/7.4.2/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution

Most of these can be resolved by importing the relevant factory and using that instead. So in the case of the Dockerfile task, we can add a new private final ObjectFactory objects and replace getDestDir's call to project.objects.directoryProperty() with objects.directoryProperty()

One is related to the build listener api (for the docker client)

- Unknown location: registration of listener on 'Gradle.buildFinished' is unsupported
  See https://docs.gradle.org/7.4.2/userguide/configuration_cache.html#config_cache:requirements:build_listeners

This one requires a bit of rework. Gradle has been pushing developers a bit more towards build services for cases where a task potentially wants to share state.

One is related to internal variables (i.e. task outputs)

From what I can tell, this mostly comes around due to the way tests are written, and can be confusing to track down. I was able to fix these by making (for example) the @Internal Property<String> imageId base mapped from it's imageIdFile output property. Something like imageId.set(imageIdFile.map { it.asFile.text }

One is a strange reoccurring bug, potentially related to groovy closures.

Execution failed for task ':buildImage'.
> Cannot cast object 'java.lang.Object@56ee54b7' with class 'java.lang.Object' to class 'org.gradle.api.DefaultTask'

The places I've seen this issue show up the most is when upToDateWhen captures the original task, and not properties/providers. I'm not sure if this is a groovy or gradle bug, but the easiest fix was to create a local variable, then reference that in the closure.

// for example, this line fixes the above exception.
def imageIdFile = this.imageIdFile
outputs.upToDateWhen {
    // here's where the capture gets queried
    File file = imageIdFile.get().asFile

EDIT: Another workaround seems to be manually implementing the Spec interface.