> watches your repository for new commits and continuously builds the environment
That feels wrong to me. For example, what happens if I want to check out a 1 year old commit and edit it? Will the dev environment that was used at the time be available or will it be rebuilt? If it gets rebuilt, there's no way I get any guarantees it's going to work.
IMHO most of the industry is getting it wrong when it comes to dev environments and build systems. I've always called it butterfly effect builds. You make a commit and it triggers a ton of non-repeatable builds. There's not much value in doing that for every commit IMO. What happens when something like an APT mirror fails and the whole system grinds to a halt? What happens when a runtime or dependency gets updated and breaks at exactly the worst time during the week?
I'd rather see something on a (calendar) schedule with the potential to trigger a manual build if needed. For example, skim this [1] article. That's always made sense to me and, in the context of a dev environment, why not build the base dev environment once a week (or day) and only layer in the resources / code on-demand? IE: Build the things I don't control on a calendar schedule and only build on-demand for changes that are part of my project (using the base env).
The way I've always envisioned it is to have a stable env build once per month or per week. It's fast enough to keep everything rolling in terms of being current, yet slow enough that I'm not spending time wondering if a problem I'm debugging is caused by a change in my dev environment. I try to do the same thing as dedicated build containers for projects, but it's hard because everything is tunnel visioned on per-commit re-builds these days.