bazel and docker images: what’s the point of @go_image_base//image?

I have a src/BUILD.bazel (on MacOs):

load("@io_bazel_rules_docker//go:image.bzl", "go_image")
load("@io_bazel_rules_go//go:def.bzl", "go_binary", "go_library")
load("@io_bazel_rules_docker//container:container.bzl", "container_image")

go_image(
    name = "bazel_docker_image",
    srcs = ["main.go"],
    pure = "on",
)

The works without error with:

bazel build //src:bazel_docker_image

showing:

INFO: Analyzed target //src:bazel_docker_image (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //src:bazel_docker_image up-to-date:
    bazel-bin/src/bazel_docker_image-layer.tar
INFO: Elapsed time: 2.361s, Critical Path: 0.03s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action

But the tar file (which can be imported into docker as an image) merely contains only the statically linked task. The image can’t be run as a container because the image doesn’t contain, among other things,

/usr/lib/libSystem.B.dylib

So what is the point of @go_image_base//image? I thought this was supposed to make an essentially complete standalone image with all the required libs, valid entry-point etc..

If one looks in bazel-bin/external/go_image_static/image/000.tar.gz.nogz it looks like Bazel had a complete image more like what the Bazel documentation seems to suggest would be output. What gives?

In addition the Bazel doc mentions:

To address this, we publish variants of the distroless runtime images
tagged :debug, which are the exact-same images, but with additions
such as busybox to make debugging easier.

but does not offer an example.

At this point I’m better off making a container image from alpine and doing everything myself. I really want to sort this out because Bazel does in general make this docker stuff easier.

Source: StackOverflow