3 ms·

Any comments on how this would be better than Google Clouds build service? I can do 'gcloud builds submit .` right now and build containers pretty easily in the

• charliermarsh 4y ago
  The difference to me is that Depot is giving you what is effectively a dedicated build machine. That machine can take advantage of local BuildKit caching. With Cloud Build, you need to use —-cache-from and other amendments to leverage remote caching. (And I believe that caching multi-stage builds require you to explicitly bush and push every stage.) With Depot, you should in theory get all of that caching “for free”. You can also take advantage of things like BuildKit cache mounts (local directories on the host machine to cache, e.g., pip install artifacts) which AFAIK can’t be done with Cloud Build. (No affiliation with Depot but I have played around with it.)
• kylegalbraith 4y ago
  Thank you for the comment and sharing your thoughts! The first thing that comes to mind is multi-platform support. Currently, it's very slow to build multi-platform images in things like Cloud Build because you have to emulate the Arm portion of the build. We don't have timings in Cloud Build for this, but in GitHub Actions a multi-platform image build can take over an hour when building for both Intel & Arm. With Depot, those builds can take less than 5 minutes because we build the image for both architectures in parallel on native CPU architectures. Other things where Depot might be more streamlined than Cloud Build is that persistent caching is automatic. The dedicated build machines for each architecture have persistent SSD caches attached to them, so you don't need to save/load cache in between runs, it's just there ready to be used.
  • res0nat0r 4y ago
    Cool. Thanks for the info!