Docker buildx?

[Monica Gordillo]

Does Bitbucket Pipelines support docker buildx?

Example:

docker buildx build --platform linux/amd64,linux/arm64 -t "$IMAGE_NAME" --push .

[dparry]

Any updates on being able to use docker buildx command on pipelines without a remote host? Just searching it appears GitHub allows this to take place. https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/ 

Any thoughts on making this happen?

[Patrick Nelson]

I'm just trying to do regular builds now it seems that this is failing because buildx is becoming the default. Simply disabling buildx really doesn't seem like it's going to be a good long term solution to this. 

# This is just a hack...
export DOCKER_BUILDKIT=0

What do we do long term when the hack/workaround of explicitly disabling the new defaults no longer continue working, especially if Docker just decided they no longer want to support the legacy builder? Are we boned? 🤔

---

Edit (2024-03-12): While I'm here, I wanted to update what my longer term fix for this was. Since Bitbucket Pipelines does at least expose it's own docker binary, you can use that without hacky environment variable overrides like the above, e.g.:

# Ensure the Pipelines managed "docker" binary is used instead of the one built into the image by
# ensuring /usr/bin takes precedence over /usr/local/bin (required for BuildKit support, i.e. buildx). See:
export PATH=/usr/bin:$PATH

See also https://community.atlassian.com/t5/Bitbucket-questions/Docker-build-failing-for-buildkit-with-error-authorization/qaq-p/2377667#M94515

[Dmytro Petrenko]

Hello Guys, so am i able to create multi arch docket buildx build for my image in bitbucket pipeline?

[Justin Thomas]

@Monica Gordillo Currently building multi-arch images is only supported using a self-hosted runner. An example can be found here

[Mathieu Lemay]

Are there any plans on supporting this in the cloud runners? The point of using bitbucket cloud is to not self host things.

[Justin Thomas]

@Mathieu Lemay Yes, we will be supporting it on cloud runners. We are currently currently blocked by a bug in BuildKit. We will be enabling BuildKit on cloud runner once the bug is fixed or when we find a workaround.

[Xavier Serrat Bordas]

Hi @Justin Thomas @Mathieu Lemay , it seems that there's a new docker version where the bug may be fixed (version 20.10.15). Did you try it? See https://github.com/moby/buildkit/issues/2087#issuecomment-1121740254

Thanks in advance!

[Norbert C]

HI @Xavier Serrat Bordas 

Thank you for your reply. I'd like to inform you that we've already rolled out the upgrade to Docker 20.10.15. You can read further about this upgrade on the following site: https://community.atlassian.com/t5/Bitbucket-articles/Bitbucket-Pipelines-Docker-client-upgrade/ba-p/2056982

Best Regards,
Norbert
Atlassian Bitbucket Cloud Support

[Xavier Serrat Bordas]

Thanks Norbert! I'm going to take a look

[Tomasz Michalak]

Hi, I checked the new docker upgrade and it looks that the buildx plugin is not available OOTB.

- Running with the default docker image:

name: 'Verify docker'
services:
 - docker
script:
 - docker version
 - docker buildx create buildx-context
 - docker buildx build --platform linux/amd64,linux/arm64 --push -f Dockerfile -t buildx-check:latest .

The output is:

docker buildx create buildx-context<1s
+ docker buildx create buildx-context
docker: 'buildx' is not a docker command.
See 'docker --help'

[Tomasz Michalak]

Doing some more research I tried to run:

name: 'Verify docker'
image: docker:20.10.15
services:
- docker
script:
- docker version
- docker buildx create buildx-context
- docker buildx build --platform linux/amd64,linux/arm64 --push -f Dockerfile -t buildx-check:latest .

The buildx plugin looks fine, I can create buildx context:

+ docker buildx create buildx-context
friendly_sinoussi

However, when I try to run buildx build:

+ docker buildx build --platform linux/amd64,linux/arm64 --push -f Dockerfile -t buildx-check:latest .
#1 [internal] booting buildkit
#1 pulling image moby/buildkit:buildx-stable-1
#1 pulling image moby/buildkit:buildx-stable-1 4.1s done
#1 creating container buildx_buildkit_default 0.0s done
#1 ERROR: Error response from daemon: authorization denied by plugin pipelines: --privileged=true is not allowed
------
> [internal] booting buildkit:
------
error: Error response from daemon: authorization denied by plugin pipelines: --privileged=true is not allowed

we have no permissions to to that.

Any suggestions?

[Elia Perenzin]

It seems like privileged is not supported on bitbucket pipelines. Therefore you can not use buildx.

What you could do is to build the containers separately and combine them into a manifest.

pipelines:
default:
- step:
image: docker:20.10.15
services:
- docker
script:
- docker build --platform linux/amd64 -t pipeline-test:amd64 .
- docker build --platform linux/arm64 -t pipeline-test:arm64 .
- docker manifest create pipeline-test:latest pipeline-test:amd64 pipeline-test:arm64
- docker manifest push pipeline-test:latest

 Don't forget to add DOCKER_BUILDKIT=1 to repository variables.

[Revil-BE]

@Elia Perenzin I try to build with `docker manifest`, but the `--platform linux/arm64` build failed in `RUN apt-get update`

exec /bin/sh: exec format error
#5 ERROR: executor failed running [/bin/sh -c apt-get update && apt-get install ...]

`DOCKER_BUILDKIT=1` is enabled.

[Revil-BE]

Looks like

--platform 

option is disabled for security reasons

[Elia Perenzin]

You are totally right, it is definitely not possible to build arm64 images :(

[Xavier Serrat Bordas]

Yep... what I'm doing at the moment is to generate the build using `docker buildx build` in another server where docker is installed via SSH but it would be great to have the whole feature in the pipeline.. Because right now I'm dealing with docker cleanup things due disk usage (layers, volumes, ...). I hope we can have this issue solved very soon :)

[Xavier Serrat Bordas]

I would like to link this issue: https://community.atlassian.com/t5/Bitbucket-questions/Can-I-keep-Docker-images-between-Pipeline-steps/qaq-p/748273#U2098243

We could do a workaround if we're capable of sharing docker images between pipeline steps. My idea is to create a parallel step with 2 pipelines and then a third final step:

- parallel:

    - step: # Build docker image for ARM64

    - step: # Build docker image for AMD64

- step: # Create manifest based on previously built images <- in this step we need the images created in the previous steps.

Is it possible without exporting/importing the image (using docker save/load) and define an artifact?

[Richard Quadling]

@Xavier Serrat Bordas Would the image/layer/etc be available if you enable the docker cache?

I use caching a lot for collating artifacts from parallel pipelines for our application pipelines, but these aren't using Docker as their target environment ... so untested idea for docker building.

[Xavier Serrat Bordas]

Yes, it would @Richard Quadling . But the way I'm solving the building of the image for both architectures is by using another server for running the `docker buildx`.

[Prithvi Sathiya]

Trying to build for multi-arch images via `buildx`, and i am using the `docker:20.10.15` image with self hosted linux runner, but still getting the error:

```

#1 ERROR: Error response from daemon: authorization denied by plugin pipelines: --privileged=true is not allowed

```

Is it still currently not possible to run `buildx` within a self hosted runner??

[reloadly]

Hi @Justin Thomas
Any updates on this, it's becoming a show stopper for a lot of us.
Thanks!

[Karan_Thakkar]

Bumping this, is an issue for me as well

[Hendrik]

2024 and still no buildx?

[Daniel Schealler]

I'm in the early phases of setting up a large project with a microservice backend architecture, and I've just started experimenting with docker scout just to see if my early images are of good quality or not.

A reccomendation from docker scout has been to add provenance attestations to images I build and push to my repository.

https://docs.docker.com/build/attestations/slsa-provenance/

It turns out that the --provenance and --attest flags are both part of buildx. If buildx is firmly disabled on bitbucket pipelines, then that is a blocker to me complying with that reccomendation from docker scout.

If there's no workaround for this on pipelines, and if I can get this working with GitHub Actions, then that will justify the time and effort to switch over.

[Marko Vušak]

Hi @Justin Thomas 

Is there any update on enabling buildx on cloud?