JIB Extension and docker layers

[fbotis]

I'm using jib extension to generate the docker container but I noticed that even if I just do a application.properties code change (basically changing only the "app" layer) the digest of the lib layer changes as well so when I do a docker pull it has to download all the "lib" layer again (which is the bigger part of the app)

See below screenshot (above the first version of the container and below the one where I just did a config change in application.properties)

I suspect this might be related to the ArcProcessor

Do you guys know if there's any workaround this so the "lib" layer doesn't change if the content doesn't either?

[quarkus-bot[bot]]

/cc @geoand

[geoand]

Changing application.properties could actually result in very different Quarkus behavior as you could be changing build time properties.

I wish we had a separation between application-runtime.properties and application-buildtime.properties which would allow us to make such a distinction, but we don't...

[fbotis]

Do you think setting the timestamp of the files to a constant would fix that problem , in io.quarkus.container.image.jib.deployment.JibProcessor#addLayer

addLayer(jibContainerBuilder, nonFastChangingLibPaths, libsMainPath, "fast-jar-normal-libs", isMutableJar, now);

Instead of now use EPOCH_TIMESTAMP for example?

[geoand]

You can certainly try it out :)

[fbotis]

I think there's no point of using jib at all if the behavior is to change the lib layer each time...I think also the documentation is wrong (from https://quarkus.io/guides/container-image):

The extension quarkus-container-image-jib is powered by Jib for performing container image builds. The major benefit of using Jib with Quarkus is that all the dependencies (everything found under target/lib) are cached in a different layer than the actual application making rebuilds really fast and small (when it comes to pushing). Another important benefit of using this extension is that it provides the ability to create a container image without having to have any dedicated client side tooling (like Docker) or running daemon processes (like the Docker daemon) when all that is needed is the ability to push to a container image registry.

Either that, either I'm using it wrong :)

[fbotis]

@geoand I updated JibProcessor to use Instant.EPOCH instead of now locally and gave it a go, looks like it solves the problem, now the "lib" layer has the same digest on multiple builds

JibProcessor.java:494

addLayer(jibContainerBuilder, nonFastChangingLibPaths, libsMainPath, "fast-jar-normal-libs",
                        isMutableJar, Instant.EPOCH);
                        
addLayer(jibContainerBuilder, new ArrayList<>(fastChangingLibPaths), libsMainPath, "fast-jar-changing-libs",
                        isMutableJar, Instant.EPOCH);

Shall I create a ticket and a PR for this?

[geoand]

Yes please. We'll need to hide this change behind a configuration option (that is false by default to keep backwards compatibility)