Can this be used with docker-build-push action

[kingdonb]

Looks like it might depend on:

• add "env" driver that connects to $BUILDKIT_HOST docker/buildx#23 (which is already merged)
  or
• Configure to use existing buildx builders on Kubernetes cluster? docker/setup-buildx-action#111

My intended use case is, to manage a persistent cache. I'll be attaching my own builders and I do not want to throw away the full image cache after the build is complete, but keep it around for a next build. I didn't see it documented here, so I went ahead and did some research connecting the dots. It looks like it may be ready / almost ready to use.

I'd like to find out and document if necessary the versions required to access this, so I can precreate builder nodes and schedule them on repos where they are needed as an attachment. 👍 great addition to the ecosystem here, thank you.

[baschny]

@kingdonb I do not understand what you mean with "Can this be used with docker-build-push action". This is exactly why you setup "buildx", to use with a later docker-build process (such as docker-build-push action).

What commands do you need to run in order to "attach your own builders"? If you explain a bit of the technicality you require to do, we might be able to incorporate it here.

[kingdonb]

I am not sure there's any change needed, I am knee deep in different build workflows and did not want to lose track of this one. I have not had a chance to exercise it and understand whether it will do what I need or not yet, but those linked issues should give a sense.

When I run docker-build-push action, it should invoke whatever builder is selected by setup-buildx-action. This append-buildx-action runs after setup-buildx. It's meant to take builders which I have provisioned however, manually, and append them to the builder set, so when I do a multiarch build, buildx will know which builders it has access to, and we can avoid using qemu. That much I think is understood.

I think in my environment, I probably won't be opening SSH access to builders, they will be hosted on Kubernetes and exposed on the local service subnet, with connections authenticated by service mesh or some other. I'm not really sure how that should be set up.

But I see that:

• Add remote driver docker/buildx#1078

has only merged in April, so I assumed whatever configuration is needed to use these features together is as of yet undocumented.

This is not a bug report, I have yet to try it out, I will soon; sorry to contribute noise, but I did not want to lose track of this repo as it looked like a critical missing piece for my multiarch build.