skip to content

Explain the difference between the jib, jibDockerBuild, and jibBuildTar tasks and when you would use each.

level: middleimportance: must knowfreq 50%

answer

  1. jib → registry, no daemon
  2. jibDockerBuild → local daemon
  3. jibBuildTar → tar file
  4. same image, different sink
  5. CI uses jib

basics

~10 s

jib pushes the image to a registry. jibDockerBuild loads it into the local Docker daemon. jibBuildTar writes the image to a tarball file. Choose by destination.

solid answer

~40 s

All three assemble the same layered image; they differ only in **where the image goes**. `jib` builds and pushes straight to the registry named in `to.image`, needing only registry credentials and **no Docker daemon** — this is the canonical CI task. `jibDockerBuild` builds and loads the image into the **local Docker daemon** so it appears in `docker images`; it requires a daemon and is mainly for local testing or further local manipulation. `jibBuildTar` writes the image as an OCI tarball to `build/jib-image.tar`, which you can `docker load`, scan offline, or hand to another pipeline stage — also daemon-free. So: registry → `jib`, local Docker → `jibDockerBuild`, file/offline → `jibBuildTar`.

code

bash · 10 lines
bash
# CI: push directly to registry, no daemon
./gradlew jib -Djib.to.image=ghcr.io/acme/app:$GIT_SHA

# Local smoke test: load into Docker
./gradlew jibDockerBuild
docker run --rm ghcr.io/acme/app:latest

# Offline artifact for scanning
./gradlew jibBuildTar
docker load --input build/jib-image.tar

go deeper

for a junior

Name the three tasks and their destinations: registry, local Docker, tarball.

for a middle

Map each task to its use case and state which need a daemon vs registry credentials.

for a senior

Justify choosing jib in CI for daemon-free pushes and jibBuildTar for offline scanning stages.

for a principal

Design a pipeline that builds a tarball once, scans it, then pushes — minimizing daemon dependence and re-builds.

## One image, three destinations Jib computes the image (layers, config, manifest) identically for all three tasks. The task only chooses the **output target**. ## `jib` — push to registry Builds and pushes directly to `to.image` using the registry API over HTTPS. It needs registry **credentials** (from `~/.docker/config.json`, credential helpers, or the `to.auth` / `from.auth` blocks) but **no Docker daemon**. This is what you run in CI: no privileged daemon socket, layer caching against the registry, fast incremental pushes. ```bash ./gradlew jib \ -Djib.to.image=ghcr.io/acme/billing:$GIT_SHA ``` ## `jibDockerBuild` — load into local Docker Builds the image and loads it into the **local Docker daemon** (equivalent to `docker load`), so `docker images` and `docker run` see it. Requires a running daemon and the `docker` CLI on PATH. Use it to smoke-test the exact image locally before pushing. ## `jibBuildTar` — write a tarball Writes the image to `build/jib-image.tar` in OCI/Docker tar format. Daemon-free. Handy when: - a later pipeline stage does the push, - you want to run a vulnerability scanner on the artifact offline, - the build agent has no registry access. You can then `docker load --input build/jib-image.tar`. ## Picking the right one | Need | Task | |------|------| | CI push, no daemon | `jib` | | Test locally in Docker | `jibDockerBuild` | | Offline artifact / scan / deferred push | `jibBuildTar` | ## Credentials note Only `jib` and `jibBuildTar`-then-push touch the registry. `jibDockerBuild` needs daemon access, not registry creds (until you push the loaded image yourself).

  • Your CI agent has no Docker daemon. Which Jib tasks still work?
    `jib` (registry push) and `jibBuildTar` (tarball) both work daemon-free. Only `jibDockerBuild` needs the daemon.
  • Where does jibBuildTar write its output by default?
    To `build/jib-image.tar` in the project's build directory.

saying these in an interview costs you the question

  • Saying jib needs a Docker daemon.
  • Confusing jibDockerBuild (load locally) with jib (push to registry).
  • Claiming the three tasks produce different image contents.

context

resolving links…