Is there a configuration-cache compatible way to access

project.version

during a task action?

Make it a task input

I suppose it's not a lazy property, so reading it eagerly shouldn't be a risk (if it would change, you've got bigger problems). Sometimes it's the most obvious solution. Thanks 🙂

if you do something like

abstract class MyTask : DefaultTask() {
    @get:Input
    val version: String = project.version.toString()
}
tasks.register<MyTask>("myTask")

or

abstract class MyTask : DefaultTask() {
    @get:Input
    abstract var version: Property<String>
}
tasks.register<MyTask>("myTask") {
     version.set(project.version.toString())
}

then it'll be captured when the task is first configured, and if you do something like

abstract class MyTask : DefaultTask() {
    @get:Input
    abstract val version: Property<String>
}
tasks.register<MyTask>("myTask") {
    version.set(project.provider { project.version.toString() })
}

then it'll be captured at the end of configuration

wouldn't it need to be a

Property<String>

that is set from

project.providers.gradleProperty("version")

? I guess that assumes you have a single version for a whole build...

project.providers.gradleProperty("version")

would only work if the version is actually coming from a Gradle property like when you have it in

gradle.properties

, but even then the version could be changed in the build script or by a plugin. Safest currently should be the last variant in the comment before yours, having a

Provider<String>

in the task like you should always have and setting value or convention to a provider that reads it from

project

. Without configuration cache it will then be read when the inputs for the task are fingerprinted, with configuration cache at the time the configuration cache entry is calculated. Hopefully with Gradle 10 and the great propertyization it will maybe be a

Provider<String>

in

Project

already.

I suppose it's not a lazy property

Technically it is any object, so it can be lazy, a lot of semver plugins do that, so you should avoid calling it eagerly.

Our usage is as part of a settings plugin to handle our version management. So we're in the case where I think it can be considered safe to do so 🙂