574 karma · joined September 6, 2017
Blog at https://blog.kylegalbraith.com
Previously at: Era Software, Thorn, Zapproved
Previously built: https://ultimatefantasysupercross.com/ https://kylegalbraith.com/learn-aws/ https://kylegalbraith.com/learn-by-doing/
kyle@depot.dev
Happy to answer any questions or hook anyone up with an extended trial that wants to move things over to it.
We’d need more details around what you’re seeing. It is true that if auth across GitHub is broken than we can’t copy your actions out to be used by Depot CI. However, we have a solution in the works for that as well.
In short, Depot CI, our own engine and control plane is not dependent on upstream actions control plane. But still has to listen for commit events to know if/when to run jobs on things like PRs. This to is being removed in the future.
I couldn’t agree more. It’s always felt odd to me that the entire performance of CI is pretty much pushed out of the primitives and requires an immense amount of custom bash scripts and the like. That kind of flexibility isn’t inherently bad. But there should be primitives that are fast by design baked into the system as well.
Parallel steps is one of those things that unlocks a lot when it’s baked into the system.
It looks and sounds incredibly powerful on paper. But the reality is drastically different. It's a big glob of homegrown thoughts and ideas. Some of them are really slick, like build deduplication. Others are clever and hard to reason about, or in the worst case, terrifying to touch.
We had to fork BuildKit very early in our Depot journey. We've fixed a ton of things in it that we hit for our use case. Some of them we tried to upstream early on, but only for it to die on the vine for one reason or another.
Today, our container builders are our own version of BuildKit, so we maintain 100% compatibility with the ecosystem. But our implementation is greatly simplified. I hope someday we can open-source that implementation to give back and show what is possible with these ideas applied at scale.
Sounds strange to say as someone who has a product that is built around making GitHub Actions exponentially faster to close these feedback loops faster.
But I can honestly say it's only really possible because the overall system with GitHub Actions is so poor. We discover new bottlenecks in the runner and control plane weekly. Things that you'd think would be simple are either non-existent, don't work, or have terrible performance.
I'm convinced there are better ways of doing things, and we are actively building ideas in that realm. So if anybody wants to learn more or just have a therapy session about what could be better with GitHub Actions, my email is in my bio.
We will continue to do our best to provide the fastest GHA runners and keep them cheaper than GitHub-hosted runners.
To your second statement, I generally agree. Sounds strange to say given we're in the business of GHA runners. But it's just not a performant or reliable system at scale. This change from GitHub doesn't smell of a company that wants to do right by it's users.
If you are interested in what is up next for us at Depot, feel free to ping me via the email in my bio. I think you'll be quite interested in what we are doing.
We (Depot) are sponsoring this year and have a private leaderboard [0]. We’re donating $1k/each for the top five finishers to a charity of their choice.
All that said, to have an outage reported turned around practically the same day, that is this detailed, is quite impressive. Here's to hoping they make their changes from this learning, and we don't see this exact failure mode again.
That said, knowing how you get to profitability or what you need to change in your model to get to it are fundamental things to know. But just because Linear did it the way they’ve outlined here, doesn’t mean that is what will work for your model.
This is really cool. I’ll probably see if I can make it my new tab background in Chromium.