Gradle puzzler for you all. Consider the following:

abstract class PrintMessageTask : DefaultTask() {

  @get:Input
  abstract val inputMessage: Property<String>

  @get:OutputFile
  abstract val outputFile: RegularFileProperty

  @TaskAction
  fun run() {
    val message = inputMessage.get()
    println(message)
    outputFile.asFile.get().writeText(message)
  }
}

project.tasks.register<PrintMessageTask>("printMessage") {
  inputMessage.set(kotlin.random.Random.Default.nextInt().toString())
  outputFile.set(
    project.layout.buildDirectory.file(
      "outputs/logs/message.txt"))
}

Do you think that task will always be up to date, or never up to date? Do you think the answer changes if you're using the configuration cache?

Cheating: obviously you wouldn't be asking if it didn't change when CC is enabled

that's my experience

So, maybe the CC doesn't understand Random is a "changing input"

already done https://github.com/gradle/gradle/issues/20538

Yeah, memoization like Haskell at it's best

I don’t think this is a bug. It’s expected with the CC. You somehow need to tell Gradle that a value is computed if you grab it from somewhere “outside” of Gradle’s domain/scope. And

Random.Default.nextInt()

is a ‘computation’ Gradle does not know anything about. I assume this fixes it?

Jendrik, if not a bug, at least a very unintuitive side effect, and very likely to produce a lot of bug on third party plugins.

Definitely! Just wanted to point this out from a CC implementation perspective. I know it’s very difficult to deal with from the usability perspective. In particular for existing builds and plugins which did not follow these new paradigms. One of the reasons why getting the CC to a stable feature already takes so long and will probably still take much longer. Gradle should probably give an error if it can. But I am not sure if all these things can be detected (in a cheap way).

and will probably still take much longer

not that we can't use it, but.. 😢

As Jendrik wrote, this is expected. For changing values you should implement a

ValueSource

https://docs.gradle.org/current/javadoc/org/gradle/api/provider/ValueSource.html

I agree, but I brought it up because my initial reaction was "wow! that's not intuitive at all." And then I became afraid for the world of community plugin authors if anything, this really shows the value of testing one's plugins. but a plugin author has no control over the context in which their plugin is applied. and creating test fixtures should be easier

Related https://github.com/gradle/gradle/issues/20538