Add support for depot.dev

[flemzord]

Is your feature request related to a problem? Please describe.

I would like to improve the build time of my Docker images

Describe the solution you'd like

I wish I could tell GoReleaser to use depot.dev instead of buildx or podman

Describe alternatives you've considered

No longer use GoReleaser to build my Docker images

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

[jacobwgillespie]

Hey! 👋 I'm one of the cofounders of Depot, I'd love to see an integration with GoReleaser!

For some background, Depot provides hosted BuildKit/buildx builders as a service. The depot CLI wraps buildx build with auth for the remote builder, so depot build ... accepts all the same CLI flags as docker buildx build would.

I think the direct way to integrate Depot and GoReleaser would be to offer a use: depot backend that calls depot build --load ... in place of the current docker buildx build. That would behave similarly to the use: buildx backend.

A more optimized integration would be to integrate with buildx's --push flag - you can skip downloading the built container to the local Docker image store by not including --load and instead calling depot build --push. That buildx flag both builds and pushes the image directly from the remote buildx builder, which saves both the network time and the time tarballing the image into Docker's format. This might be more involved though, since my understanding is that GoReleaser expects build and push to be two separate steps today.

Let me know your thoughts and what I can do to help.

[caarlos0]

if anyone wants to try to pr it, I can review.

as far as the build and push in a single go, its how we implemented Ko, maybe its worth having its own implementation like Ko does too...

[caarlos0]

is this still of interest?

[flemzord]

Yes :)

[caarlos0]

Is anyone interested in working on this integration?

[caarlos0]

I'm not interested in working on this, so, if no one volunteers, I'll close the issue.

That said, I think a better integration would be to make the depot cli configure auth on the client, and then the user can use the buildx builder as usual.

[jacobwgillespie]

Hey, so an update on Depot, it now supports installing itself as a buildx driver - effectively you can run depot configure-docker and it will point the local buildx at Depot, so that calling buildx should just work. More details.

That said, I think there's one blocker and one rough edge with potentially using it with goreleaser:

• Currently goreleaser calls docker buildx build with --builder default, so that would override the custom buildx builder that Depot installs:

  goreleaser/internal/pipe/docker/api_docker.go

  Line 76 in 962429d

  base = []string{"buildx", "--builder", "default", "build", ".", "--load"}

• Since Depot is a remote buildx builder, the image built with docker buildx build needs to be loaded back to the local machine so that docker push works. This is particularly inefficient with native buildx, since it creates a legacy Docker tar of the entire image and loads it with docker load. We've made this faster with depot build by rewriting the --load to instead operate like a docker pull from the remote buildkit server, since we control both client and server. But besides inefficiency, pulling the image back to push it also has other issues like multi-platform images.

I think the better solution for both buildx and Depot would be to call docker buildx build with --push, so that the build and the push were combined. That would eliminate the inefficiency of creating the intermediary Docker image tarball and would instead push the image directly from the buildx builder, whether that builder was local or remote.

You had mentioned that the Ko driver has the concept of doing a build and push in the same pass. I'm not sure what would be involved in conditionally doing the same for buildx. Let me know if you have any thoughts here.