Running "./gradlew jibDockerBuild" two times in a row should be a no-op

[sschuberth]

Description of the issue:

I was accidentally running ./gradlew jibDockerBuild two times in a row without making any modifications in between.

Expected behavior:

I would expect this to be a no-op on the Gradle-level, marking the jibDockerBuild task to be UP-TO-DATE.

Steps to reproduce:

Check out e.g. https://github.com/heremaps/oss-review-toolkit/tree/jib and run

./gradlew jibDockerBuild
[...]
BUILD SUCCESSFUL in 23s
68 actionable tasks: 1 executed, 67 up-to-date

and again

./gradlew jibDockerBuild
[...]
BUILD SUCCESSFUL in 4s
68 actionable tasks: 1 executed, 67 up-to-date

Note that while the second run was significantly faster (probably because the result was cached on the Docker-level), that 1 task was still executed and only 67 were up-to-date.

Environment:

Ubuntu 18.04

jib-gradle-plugin Configuration:

plugins {
    id 'com.google.cloud.tools.jib' version '0.9.11'
}

jib.to.image = 'ort:latest'

Additional Information:

Docs about how Gradle's up-to-date checks work:

https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:how_does_it_work

[coollog]

Hi @sschuberth , thanks for filing this issue! Although it does seem like the task should just skip as up-to-date, Jib builds work a bit differently from Docker builds in that the base image is not stored (only layers are cached). Therefore, Jib must at least check if the base image has changed via a request to its registry. We plan to potentially add caching of base images if they are specified via a digest so that in those cases the task could skip the base image check request.

[sschuberth]

Thanks for the clarification, I'll close this then for now!