v2: docker driver doesn't support auto-push

[ngraef]

I'm experimenting with the v2 branch and ran into an issue with the basic use case below. Notice it's using the default builder (no setup-buildx-action step) with the docker driver.

jobs:
  build:
    - uses: actions/checkout@v2

    - uses: docker/login-action@v1
      with:
        registry: ${{ env.REGISTRY }}
        username: ${{ env.USER }}
        password: ${{ secrets.PASSWORD }}

    - uses: docker/build-push-action@v2-build-push
      with:
        context: .
        tags: ${{ env.REGISTRY }}/myapp:latest
        push: true

The output for the build step is:

Run docker/build-push-action@v2-build-push
📣 Buildx version: 0.4.2
🏃 Starting build...
/usr/bin/docker buildx build --tag myregistry.io/myapp:latest --iidfile /tmp/docker-build-push-Ghos6S/iidfile --file ./Dockerfile --push .
auto-push is currently not implemented for docker driver
##[error]The process '/usr/bin/docker' failed with exit code 1

I realize the error is coming from buildx upstream, but considering this action is called "build-push", I think users would expect this functionality to be implemented by the action if the underlying tool doesn't support it — or at least have a large warning in the README. My use case is more complex than this example, and part of the appeal of this action is that it seamlessly handles pushing a dynamic number of tags.

[crazy-max]

@ngraef

auto-push is currently not implemented for docker driver

The error message will be more explicit in a further release. See docker/buildx#360.

I think users would expect this functionality to be implemented by the action if the underlying tool doesn't support it — or at least have a large warning in the README.

I think it's better to separate the build part from the setup part. As would for example setup-go which only installs Golang. But thanks for your input, will consider that.

[ngraef]

I think it's better to separate the build part from the setup part.

I agree. I really like the decision to extract login and setup from v2. 👍

In this case, the environment is already set up to use the docker driver. I don't expect this action to change that setup. I do expect an action called docker/build-push-action to be able to push images built with docker.

Thanks for considering, and great work with v2 so far!

[crazy-max]

Version 2 has been merged to the main branch and is therefore available via uses: docker/build-push-action@v2 (mutable tag).

As a reminder, this new version changes drastically and works with 3 new actions (login, setup-buildx and setup-qemu) that we have created. Many usage examples have been added to handle most use cases.

And it should fix this current issue. Don't hesitate if you have any questions.

[ngraef]

And it should fix this current issue.

@crazy-max It doesn't look like this issue has been fixed yet.

[crazy-max]

@ngraef Now the README with its examples clearly shows the use of setup-buildx within this action.

[ngraef]

The result is the same with the setup-buildx step.

jobs:
  build:
    - uses: actions/checkout@v2

    - uses: docker/setup-buildx-action@v1
      with:
        driver: docker

    - uses: docker/login-action@v1
      with:
        registry: ${{ env.REGISTRY }}
        username: ${{ env.USER }}
        password: ${{ secrets.PASSWORD }}

    - uses: docker/build-push-action@v2
      with:
        context: .
        tags: ${{ env.REGISTRY }}/myapp:latest
        push: true

Again, I know this is an upstream limitation, but I believe it makes sense for docker/build-push-action to support this basic use case despite buildx's lack of support for it.

[crazy-max]

@ngraef

I believe it makes sense for docker/build-push-action to support this basic use case despite buildx's lack of support for it.

Our goal is to avoid hacks around this action and be as closed as possible of the buildx build command. @tonistiigi can tell us more about it.

[tonistiigi]

I'm ok with a hack in buildx that just runs docker push after build until docker driver doesn't support full buildkit features(pending on containerd storage) if anyone has cycles to implement it.

[wbobeirne]

Surprised to find this closed, I also ran into this and was somewhat confused. Unfortunately I have to use the docker driver since multiple images in my build rely on "base" images being built on that same machine. Would definitely like to see this supported.

[Locustv2]

@wbobeirne - same here. How are you using the docker driver?