Depot's company blog covers fast container builds, CI, GitHub Actions caching, and related build infrastructure.
HN commenters mention Depot as a vendor for faster builds and GitHub Actions alternatives; its founder joins threads, and it posts job listings.
GitHub Actions started off great as they were quickly iterating, but it very much seems that GitHub has taken its eye of the ball and the improvements have all but halted.
It's really upsetting how little attention Actions is getting these days (<https://github.com/orgs/community/discussions/categories/actions?discussions_q=is%3Aopen+category%3AActions+sort%3Atop> tells the story -- the most popular issues have gone completely unanswered).
Sad to see Earthly halting development and Dagger jumping on the AI train :(. Hopefully we'll get a proper alternative.
On a related note, if you're considering https://www.blacksmith.sh/, you really should consider https://depot.dev/. We evaluated both but went with Depot because the team is insanely smart and they've solved some pretty neat challenges. One of the cooler features is that their caching works with the default actions/cache action. There's absolutely no need to switch out popular third party actions in favor of patched ones.
Instances are constantly booting up because most instances live <30d. Boot time in terms of how soon a node is fully booted and joined to the EKS apiserver and ready for workloads is approx 2.5-3min. There are lot of parts involved in getting to this point though, some of which would not matter if you're not using EKS. Also this is not something we measure super closely as from a user perspective it is generally imperceptible.
A possibly better metric for your particular case (assuming you're interested in fastest bootup possibly achievable) is from our self-managed github-actions runners. Those boot times are in the 40-50s range. This is consistent with what others see, as far as I know. A good blog on this topic - including how they got boot-to-ready times down to 5s - that you might be interested in from the depot.dev folks: https://depot.dev/blog/github-actions-breaking-five-second-barrier
Depot (W23) | Enterprise Support Engineer | Remote (UK, Europe) | Full-time | €100K - €160K | https://depot.dev
Depot is the fastest place to build software. We accelerate builds for customers using GitHub Actions, Docker, Bazel, Gradle, and more. We're seeking our first Enterprise Support Engineer to become a customer-facing expert on build optimization.
We're looking for someone with DevOps / CI consulting experience - you'll work directly with customers as the subject-matter expert on best practices, helping migrate legacy infrastructure, and working directly with the founders on product gaps.
Bonus: experience with Docker buildx, API integrations, or previous CI consulting.
For more details, and to apply: https://www.ycombinator.com/companies/depot/jobs/NdCr76D-enterprise-support-engineer
I’ve always been annoyed with the sequential character of jobs in GitHub Actions – that it is impossible to run steps in parallel, when applicable, without moving the job’s logic away from the the .yaml constructs into, say, bash scripts. My ideal runtime for a CI workflow should in my view leverage the model of a DAG and the parallelism made plausible by that to the fullest. Depot CI seems to have addressed this quite well – https://depot.dev/docs/ci/how-to-guides/parallel-steps. I migrated a side project to use it now, and it’s working great – I am seeing some great speed-ups.
This tool has really cool potential!
Just one problem I noticed imminently that prevents me from using this, the docker agent container[1] isn't multi-architecture, this will be an issue on Apple Silicon devices. This is something I have some experience setting up if you are looking for help, though will take some research to figure out how to get going in github actions etc.
1: https://github.com/evanrolfe/trayce_agent/
EDIT: quick search found this post, tested on a side project repo it works great: https://depot.dev/blog/multi-platform-docker-images-in-github-actions
This is fairly similar in concept to what we do over at depot.dev https://depot.dev/blog/depot-magic-explained
We've found that BuildKit has several inefficiencies preventing it from being as fast as it could be in the cloud, especially when dealing with simultaneous builds (common in CI). That led us to create our own optimized fork of BuildKit.
The number of fine-tuning knobs you can turn running a self-hosted BuildKit instance is limitless, but I also encourage everyone to try it as a fantastic learning exercise.