Depot

Just your weekly reminder that we saved developers 285,340 hours last week. 🚀

CI + API = 😀(🤖 + 🧑💻)

🚀 Sherlock can now analyze your Depot CI workflows and jobs from the dashboard. Open a workflow or job, click Ask AI in the sidebar, and ask why it failed or why it was slow. Sherlock pulls run context, attempts, step details, logs, CPU and memory metrics, and the failure diagnosis card on its own. If a failure diagnosis card already points you in the right direction, click Ask Sherlock from the card to keep digging. Same context, more depth. Included with Depot at no extra charge. https://lnkd.in/eCevzeY2

Most CI jobs run as one long serial script, even when half the work doesn't depend on the other half. Lint, unit tests, and DB-backed tests are independent, but in a single job they still run one after another. You can overlap independent steps within a single job. Two ways: Shell backgrounding: run lint, unit tests, and the DB harness with `&`, then collect exit codes. Job time drops from 2m54s to ~2m30s. But now your workflow step is a process manager: shell functions, background PIDs, `wait` calls, exit-status bookkeeping. Faster, but harder to read and review. Depot CI `parallel:` blocks: the same shape, expressed in the workflow itself. The DB branch keeps its `sequential:` order (start MySQL, wait, run tests) while lint and unit tests run alongside. ~2m29s. Basically the same speed. That's the honest part. `parallel:` doesn't magically beat shell backgrounding, it hits the same wall-clock time. The win is you don't turn a CI step into a process manager. Concurrency lives in the workflow syntax instead of buried in a script, and a branch can be a single `run:`, a `uses:` action, or a whole `sequential:` chain. Iris Scholten walks through it: https://lnkd.in/e9Q-fakU

Moving a GitHub Actions workflow to Depot CI should not feel like a rewrite. That is the point of `depot ci migrate`. It finds compatible workflows, copies them into `.depot/workflows/`, keeps `.github/` intact, maps the runner labels it can, and leaves comments where it changed anything. If your repo depends on secrets or variables, `depot ci migrate secrets-and-vars` can pull those over without you retyping values into another UI. The interesting part is what happens after the migration. You can run CI locally against uncommitted changes. You can stream logs in real time. You can search and filter them instead of expanding step after step. When a job fails, Depot CI points at the failing step, summarizes what happened, and suggests a fix. If that's not enough, you can SSH into the running job as well. That last bit matters more in an agentic coding loop than I think people realize. An agent can trigger a run, poll status, read logs, inspect a failure, patch the code, and run the workflow again before anything hits the default branch. Here is a great write-up of exactly what a lightweight migration looks like in practice 👉 https://lnkd.in/eCDrRBEa

Nested virtualization is now on by default in every Depot CI sandbox. No extra config, no extra cost. The headline use case is the Android Emulator at native speed for tests, but it also opens up full VMs for end-to-end testing (a Kubernetes cluster, for example), QEMU/KVM workloads inside a job, and hypervisor development. https://lnkd.in/diCq5R5m

Just your weekly reminder that we saved developers 243,590 hours last week. ;)

I watched a developer do this six times in a row last week. Commit. Fail. Copy logs. Paste. Fix. Fail again. He was the slowest part of his own pipeline. Here is how Depot CI kills that loop entirely: Your coding agent gets Depot CI skills baked directly into it. Programmatic access to the full CI interface. So the workflow looks like this: 1. You prompt your agent to build a feature or fix a bug 2. The agent implements the change 3. Before committing anything, the agent triggers Depot CI runs with the local file changes 4. CI passes? Great. CI fails? The agent pulls the logs, figures out what broke, and fixes it 5. The agent can even SSH directly into the machine to debug something itself All of this happens before a single commit. By the time the code is committed and the PR is open, CI has already passed. No back and forth. No copying logs into a chat window like it's 2023. The agent already handled it. The key is giving your agent the right tools and rules. Bake in rules like "once you implement the change, use the Depot CI skill to validate your change passes CI in these workflow files." That's it. The agent does the rest. This is what "human on the loop" actually looks like. You're not babysitting the feedback cycle. You're reviewing code that already works. What's the most time you've wasted going back and forth between a failed CI run and your agent?

We’ve made over 100 million builds near instant, but that's only 30% of the CI pipeline. We’re now building the CI for the next era of software development. Here's how we’re doing it. Every CI job starts from absolute zero. Check out the code. Install dependencies. Rehydrate caches. Build. Test. Deploy. That front half repeats on every single job. I lived with it for years. Most teams still do. But when I broke down where the time actually goes, I couldn't unsee it. This isn't a speed problem. It's an architectural one. Traditional CI spins up a fresh VM every time. No state. No memory. You spend the first chunk of every build just getting back to where you were five minutes ago. With Depot CI, the runner already has the code checked out, dependencies installed, caches hydrated. It starts where the last one left off. No rebuilding from zero. In practice: - Node/TypeScript workflows: saving 20-40 seconds of setup when the lint check itself is 30 seconds. Job cut in half. - Java or Rust projects: saving three to ten minutes per build. Rust lint checks that take 30-40 seconds but need three minutes of plumbing to get there. Three minutes of setup for 40 seconds of actual work. Brutal. This isn't theory. Over 100 million builds processed at Depot, 2,000 to 3,000 running at any given minute. When a new team signs up, we make their builds exponentially faster within 30 minutes. Within two days, a real human reviews their builds and says, "Fix this, this, and this." That advice helps regardless of whether they stick with Depot. That setup time compounds across every job, every PR, every developer, every day. It's not one 30-second tax. It's thousands of them. We don't ship "trust me" performance. We benchmark it. Every time. What's the heaviest setup tax in your pipeline right now?