What are the correct --output parameters for getting nerdctl build image to local (i.e. visible via

nerdctl images

)? If I leave it out, I get correct behavior, though.

I don't understand the question. If you want the image stored in the containerd namespace, you don't specify

--output

. The option exists to export the image somewhere else instead of importing it into the runtime.

This is confusing : https://github.com/docker/buildx/blob/master/docs/reference/buildx_build.md#output

The image exporter writes the build result as an image or a manifest list. When using docker driver the image will appear in docker images. Optionally, image can be automatically pushed to a registry by specifying attributes.

--output type=image,name=$IMAGE,push=false

in Docker mode (when using buildx) makes the image available locally. However, in containerd mode, the command just finishes silently and there’s no image anywhere. My point is; it seems that `nerdctl build`’s behavior unexpectedly differs from

docker buildx build

even though the APIs are very similar. It would help avoid confusion if the APIs matched in expected behavior.

Indeed, it doesn't seem to store the image locally at all. And even when it pushes to the registry, it ignores the

name=$IMAGE

parameter and pushes to the

--tag

repository instead @best-accountant-68201 :

$ nerdctl build -t registry.home/hi:there --output type=image,name=registry.home/wazzup:yo,push=true .
[+] Building 0.6s (7/7) FINISHED
 => [internal] load build definition from Dockerfile                                                                   0.0s
 => => transferring dockerfile: 68B                                                                                    0.0s
 => [internal] load .dockerignore                                                                                      0.0s
 => => transferring context: 2B                                                                                        0.0s
 => [internal] load metadata for <http://docker.io/library/busybox:latest|docker.io/library/busybox:latest>                                                      0.4s
 => [1/2] FROM <http://docker.io/library/busybox@sha256:3614ca5eacf0a3a1bcc361c939202a974b4902b9334ff36eb29ffe9011aaad83|docker.io/library/busybox@sha256:3614ca5eacf0a3a1bcc361c939202a974b4902b9334ff36eb29ffe9011aaad83>       0.0s
 => => resolve <http://docker.io/library/busybox@sha256:3614ca5eacf0a3a1bcc361c939202a974b4902b9334ff36eb29ffe9011aaad83|docker.io/library/busybox@sha256:3614ca5eacf0a3a1bcc361c939202a974b4902b9334ff36eb29ffe9011aaad83>       0.0s
 => CACHED [2/2] RUN touch /wazzup                                                                                     0.0s
 => exporting to image                                                                                                 0.1s
 => => exporting layers                                                                                                0.0s
 => => exporting manifest sha256:0012dd04372a9a766eba420c0a7aa2ad91bd4b3ef248111e383fe2ae8e77c920                      0.0s
 => => exporting config sha256:c7be383d61fc802cad6de5f81d27a72d49d3f921137c3e1919f6dded7060fa74                        0.0s
 => => naming to registry.home/hi:there                                                                                0.0s
 => => pushing layers                                                                                                  0.1s
 => => pushing manifest for registry.home/hi:there@sha256:0012dd04372a9a766eba420c0a7aa2ad91bd4b3ef248111e383fe2ae8e7  0.0s
 => [auth] sharing credentials for registry.home                                                                       0.0s
$ nerdctl images
REPOSITORY         TAG       IMAGE ID        CREATED         PLATFORM       SIZE       BLOB SIZE
rancher/rancher    latest    ae5135c25b21    39 hours ago    linux/amd64    1.5 GiB    434.2 MiB

@fast-garage-66093 Sure. Just about to head sleep, but I can do it tomorrow.

Yeah, maybe we get to see an explanation from @best-accountant-68201 by then...

btw, I would like to try out some hacking of nerdctl source. Is there some guide/advice about how to smoothly develop on macOS? Merely running

make binaries

doesn’t seem to work.

idk, but given that

nerdctl

doesn't actually run on macOS, this is maybe not too surprising. You could run the build inside the VM, so instead of

make binaries

try

rdctl shell make binaries

, but note that I haven't done it. You will need to install the required tools into the VM, like

rdctl shell sudo apk add go

and whatever else may be needed (like

make

).

@fast-garage-66093 Created ticket: https://github.com/containerd/nerdctl/issues/1117 Also, thanks for the info above.

idk, wait for @best-accountant-68201 to respond. Otherwise I would say Github :)

Yes