Add --load flag to Docker build command

[wecalderonc]

This Pull Request introduces the --load flag to the Docker build command, enhancing the development and testing workflow.

Background:

Platform: Mac M1

In the current setup, after building the Docker image, developers have to manually load the built image into their local Docker environment. This additional step can be cumbersome and may lead to inefficiencies in the development process.

I ran

gem install kamal-skiff
skiff new tester-wtf
cd tester-wtf
skiff dev

Error/Warning message:

skiff dev
Starting tester-wtf on http://localhost:4000...
[+] Building 3.6s (12/12) FINISHED                                                                                              docker-container:kamal-hamal-multiarch
 => [internal] load build definition from Dockerfile                                                                                                              0.0s
 => => transferring dockerfile: 417B                                                                                                                              0.0s
 => [internal] load metadata for docker.io/library/nginx:latest                                                                                                   3.4s
 => [auth] library/nginx:pull token for registry-1.docker.io                                                                                                      0.0s
 => [internal] load .dockerignore                                                                                                                                 0.0s
 => => transferring context: 64B                                                                                                                                  0.0s
 => [1/5] FROM docker.io/library/nginx:latest@sha256:add4792d930c25dd2abf2ef9ea79de578097a1c175a16ab25814332fe33622de                                             0.0s
 => => resolve docker.io/library/nginx:latest@sha256:add4792d930c25dd2abf2ef9ea79de578097a1c175a16ab25814332fe33622de                                             0.0s
 => [internal] load build context                                                                                                                                 0.0s
 => => transferring context: 6.37kB                                                                                                                               0.0s
 => CACHED [2/5] RUN apt-get update -qq &&     apt-get install --no-install-recommends -y git &&     rm -rf /var/lib/apt/lists /var/cache/apt/archives            0.0s
 => CACHED [3/5] WORKDIR /site                                                                                                                                    0.0s
 => CACHED [4/5] RUN echo 'include /site/config/server.conf;' > /etc/nginx/conf.d/default.conf                                                                    0.0s
 => [5/5] COPY --link . .                                                                                                                                         0.0s
WARNING: No output specified with docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load

What's Next?
  View a summary of image vulnerabilities and recommendations → docker scout quickview
Unable to find image 'tester-wtf:latest' locally
docker: Error response from daemon: pull access denied for tester-wtf, repository does not exist or may require 'docker login': denied: requested access to the resource is denied.
See 'docker run --help'.

[jeremy]

The built image is loaded by default… unless you have docker build aliased to buildx. The docker build --load invocation would normally be docker buildx build --load ….

Could get more explicit by switching to buildx with docker buildx build --load … or by setting DOCKER_BUILDX=0 to ensure we trigger the legacy non-buildx path.

[wcastillogc]

@jeremy Thanks for the review. In this case I don't know how to decide in what is the best approach. I would take the docker buildx build --load solution, to use the buildx capabilities in the future. But yes, I think i don't have the knowledge to take the best decision for this. Let me know if I should change the PR to buildx or got with legacy.

Thanks