depot CLI v2.7.2 released 🎉
If you follow our depot/cli
repository, you may have noticed that we've been shipping many new features in our CLI. We've been adding the capabilities to depot
that we've wished existed for docker build
itself. Here are the highlights of what we've added:
depot list
List your projects and builds with We've added a top-level depot list projects
command that allows you to see all your organization's projects. You can then select a given project to see all of the builds for that project.
We've also added a depot list builds
command that will list all of the builds for the project defined in your depot.json
config file, or you can pass the --project
flag to list the builds for a specific project ID. If you want to parse the output of this command, you can use the --output
flag to get the result in JSON or CSV format.
--push
Push your image to multiple registries at once with We've added the ability to push your image to multiple registries simultaneously. This is a massive speed improvement for organizations that need to push their image to multiple registries.
Before this release, running a build that tagged and pushed to multiple registries would push to registry1
and then push to registry2
serially. With this new release, we can push to both registries in parallel.
--load
and --push
at the same time
Build your image with We've also added the ability to simultaneously build your image with --load
and --push
, which means the image will be both downloaded to the local machine as well as pushed to a remote registry in one step. Previously this required running two separate builds. This is a massive speed improvement for organizations that need to push their image to a registry and load it into their local Docker daemon.
--load
Intelligent loading of only changed layers with By default, docker buildx build --load .
returns the tarball of the entire image to the client, even when the client may already have some or all of the layers cached locally. This is a massive waste of bandwidth and time compared to only loading the the new or changed layers.
With this release, we've made this more intelligent. When you run depot build --load .
locally, we send back the diff between what you have locally and what the build has produced. This means that only new or changed layers need to be downloaded to the client.
This is a massive speed improvement for organizations that need to load their image back into their local development environment.
This optimized diff also skips the need to produce a single tarball for the whole image, so even in environments that may be not have any local layers downloaded, like CI, we are able to skip the slow tar process and download the layers directly, in parallel.