Different output when using buildx vx. build

[ib-ak]

This command works fine and generates an image in ~1.3 Gb

docker build --build-arg PACKS="aws csv email excel git github gpg hubot vault xml" -t st2packs:1.0.5 st2packs-image

I am using Github Action and it uses docker buildx build command.

docker buildx build --build-arg PACKS="aws csv email excel git github gpg hubot vault xml" --tag st2packs:1.0.4 st2packs-image

This only produces 4Mb docker image with no packs copied.

[arm4b]

Thanks for sharing this observation. It would be useful for community to know that docker buildx doesn't provide expected build results.

I'm not familiar with the docker buildx, what's the difference comparing to default docker build? Looks like it's experimental feature.

[hreeder]

Looks like this is due to moby/buildkit#816

I've worked around this by using the Dockerfile approach here: https://github.com/StackStorm/st2packs-dockerfiles#building-the-st2packs-image

However, instead of the last line - FROM stackstorm/st2packs:runtime - I've instead used the contents of st2packs-runtime/Dockerfile, thus my Dockerfile looks something like this (taking the example from the README of this repo, rather than our actual one):

ARG PACKS="file:///tmp/stackstorm-st2"

FROM stackstorm/st2packs:builder AS builder
# considering you have your "local" pack under the `stackstorm-st2` dir relative to Dockerfile
# Here we copy local "stackstorm-st2" dir into Docker's "/tmp/stackstorm-st2"
COPY stackstorm-st2 /tmp/stackstorm-st2/
# Check it
RUN ls -la /tmp/stackstorm-st2

RUN /opt/stackstorm/st2/bin/st2-pack-install ${PACKS}

FROM alpine:3.13

RUN apk add --no-cache rsync
VOLUME ["/opt/stackstorm/packs", "/opt/stackstorm/virtualenvs"]

# Copy packs and virtualenvs
COPY --from=builder /opt/stackstorm/packs /opt/stackstorm/packs
COPY --from=builder /opt/stackstorm/virtualenvs /opt/stackstorm/virtualenvs

The presence of the COPY --from=builder lines in this Dockerfile helps BuildKit to know that it needs to finish working with the builder image before the output image is completed. That behaviour doesn't seem to be in place when using ONBUILD style instructions.

Given the runtime container only exists to hold the data and then copy it over to a Kubernetes volume, I'm happy with this workaround internally for our own deployment.