Gradle: Support lazy configuration of properties, specifically jib.to.image.

Today the jib.to.image is configured statically in a Gradle task or via cli arguments. This only works in very simple scenarios where Gradle is really only build/pushing the image or using static versions that are known before Gradle is invoked.

In my case, and especially important for local reproducible workflows, Gradle is building up all the JARs etc that are going into the image and versioning the image with a hash of that contents (so re-builds and re-deploys without changes are no-ops). This means the image version isn’t known ahead of time and should be calculated from the inputs, the idiomatic Gradle way to do that is to use a Provider<> i believe https://docs.gradle.org/current/userguide/lazy_configuration.html instead of a normal String.

Currently to work around this I have to do:

jib {
...
}

jibDockerBuild.doFirst {
    jib.to.setImage(jib.to.getImage() + ":version-blahblah")
}

which isn’t ideal. I’d like to be able to configure it this, which lazy configuration approach above supports I believe, like:

jib {
  ...
  to {
     ...
     image = { -> "image:${calculateImageHash()}" }
  }
}

[nhoughto]

Agree the workaround is quite simple, not very idiomatic Gradle to reach in and mess with task props in custom actions though it has other knock-on effects on up-to-date checking, configuration caching etc. The examples aren’t super clear, bit frustrating, to explain more:

abstract class Greeting extends DefaultTask {
    // A configurable greeting
    @Input
    abstract Property<String> getGreeting()

    // Read-only property calculated from the greeting
    @Internal
    final Provider<String> message = greeting.map { it + ' from Gradle' }

    @TaskAction
    void printMessage() {
        logger.quiet(message.get())
    }
}

tasks.register("greeting", Greeting) {
    // Configure the greeting
    greeting.set('Hi')
    greeting = 'Hi' // Alternative notation to calling Property.set() - only available in Groovy DSL
}

By just wrapping the task variable in a Property<String> where it used to be String you easily support my dynamic setting of that value by users of your gradle tasks, groovy handles the translation, so you can set it normally just a static string:

greeting = 'Hi'

or you can give it a closure instead to pass a more dynamic value:

greeting = provider({ -> 'something more dynamic' })

Just by changing String -> Property<String> and then accessing it via .get() instead.

[suztomo]

In the document (https://docs.gradle.org/current/userguide/lazy_configuration.html), I found cases where task implementer can lazily reference properties. But I didn’t find task users passing a lambda to a task. Do you have a specific section I should read?

(My first impression is that your workaround is more simpler than going through https://docs.gradle.org/current/userguide/lazy_configuration.html)