Can registry push be disabled?

[karlmuscat]

Can we instruct Jib to execute normally, but not push the generated images to a registry?

Reason: we would like to examine the digest generated, check whether it already exists in our repository, and only if missing, push the image.

[loosebazooka]

You can try jibBuildTar which produces an image on disk and also the image meta data files in the build directory

[chanseokoh]

Reason: we would like to examine the digest generated, check whether it already exists in our repository, and only if missing, push the image.

Wait, this is the default behavior of Jib image pushing. It pushes only those bits that are missing.

[loosebazooka]

I think this is related to #2360 ?

[chanseokoh]

This may be useful: https://stackoverflow.com/a/60869500/1701388)

The closest workaround is jib:buildTar; the goal creates a local tarball at target/jib-image.tar (path configurable with <outputPaths><tar>). Running jib:buildTar (or any jib:... goals) for the first time will build and cache everything necessary to build an image. Therefore, subsequent jib:build runs will be no-op in terms of building layers. It will only need to send layers missing in a remote registry.

Of course, one downside of the workaround is that it creates an unnecessary tarball, which may be large.

[bric3]

I usually like to inspect the images I'm developing, or for example during a CI pipeline, have an opportunity to test the build without pushing is useful.

[karlmuscat]

@bric3 You can use the buildTar to generate a local image and test it. Also see: #2531

Adding skipExistingImages in gradle or maven build will stop Jib from pushing already uploaded images with the same SHA into the remote registry.

[bric3]

jibBuildTar could help indeed for the CI, but this is not the most straightforward task I think.

Also jibBuildTar could help to inspect the image, but it's not efficient in my opinion for two reasons :

1. The tar has every layer packed as a tar.gz, so the resulting file can be significant as it doesn't profit from the local registry.
2. jibBuildTar forces a 2nd step for a developer, to load the image in docker if you need to enter a shell to test various elements.

And on a side note inspectiong image layers is really productive with dive, it is supposed to support docker-archive source dive docker-archive://project/build/jib-image.tar, but that doesn't work (dive doesn't find the layer that is in the tar), but the docker loading works fine, I need to check dive issues.

[chanseokoh]

I usually like to inspect the images I'm developing, or for example during a CI pipeline, have an opportunity to test the build without pushing is useful.

@bric3 in order to test or inspect an image (also with dive), looks like you will have to push it to your local docker daemon anyway? So you can just run the jibDockerBuild task instead of jib or jibBuildTar?

[bric3]

@chanseokoh Ah yes good point ! 🤦

I still think jib should have a toggle to disable pushing, or a separate task like jibPush. And indeed currently it's possible to achieve what we want by using jibDockerBuild locally, and program the CI pipeline to use buildTar if the branch is not a main branch.

Thanks for your patience !

[loosebazooka]

Jib is intentionally not a interface for docker. We can build image to docker (as it is a target like tar or regitsry), but we expect any user using docker to use docker cli or some othe docker tool.

The way jib builds to a registry is not through docker. Jib builds layers and then interfaces with the registry directly to push an image to it (docker is not involved).

[zhumin8]

Closing as part of cleanup. Please re-open if it's still relevant