This message was deleted.

Also same question if the task input is a provider using the configuration instead of the configuration:

provider {
  configuration.files.md5()
}

Can the CC be smart enough to not invalidate here?

For the first part if I got you right, CC should not be invalidated, as the configuration of the tasks does not change. The file contents should not be relevant as long as you do not read those file contents at configuration time. For the second part I did not understand at all what you mean. If you mean you are calculating an md5 sum over some files at configuration time (or in a provider that is set to a task property) then the CC will be invalidated. Even if the md5 would be the same with different file contents (unlikely but theoretically possible) CC would be invalidated as you read the file contents at configuration time, so the file contents are CC input, unless you do it inside a

ValueSource

. In that case only the result of the value source would make the CC invalid or not, but then is executed on every build even if CC is reused and if not reused even twice.

Yep, that was the question. I guess I wasn't clear on what "configuration time" is. But from your answer, the code that is inside a provider used as task input is executed during configuration time, right?

Exactly,

elements

is there to get a

Provider

that carries the task dependencies of the

FileCollection

. Actually I wonder that

input.set(configuration.elements.map { it.md5() })

is not invalidating the CC. I thought the providers are calculated at the time the CC entry is written and the result persisted.

I think this is the relevant code:

public ExecutionTimeValue<? extends T> calculateExecutionTimeValue() {
        if (contentsAreBuiltByTask()) {
            return ExecutionTimeValue.changingValue(this);
        }
        return ExecutionTimeValue.fixedValue(get());
    }

so if the configuration is buildable by a task then

get()

isn't called and instead the transforming lambdas are serialized instead

Ah, of course. Makes sense that task execution results cannot be serialized to CC. hen-and-egg, you know. 😄

Feels almost counterintuitive. CC works "better" if your build is more "complex"

And with this CC is reused as the task dependency is there:

abstract class Foo : DefaultTask() {
    @get:Input
    abstract val input: Property<String>

    @TaskAction
    fun foo() {
        println("input = ${input.get()}")
    }
}
val fooBucket by configurations.dependencyScope("fooBucket")
val fooElements = configurations.resolvable("fooElements") {
    extendsFrom(fooBucket)
}
val bar by tasks.registering(Sync::class) {
    from(file("foo.txt"))
    into(layout.buildDirectory.dir("bar"))
}
dependencies {
    fooBucket(bar.map { it.outputs.files })
}
val foo by tasks.registering(Foo::class) {
    input = fooElements.flatMap { it.asFileTree.elements }.map { it.single().asFile.readText() }
}

Yep 👍