For example, this sure does look like Dagger <https://github.com/dagger/dagger#what-is-dagger> in its use of golang-as-ci <https://docs.dagger.io/quickstart/daggerize#construct-a-pipe...> and plausibly "run ci locally"
Dagger doesn't ship with a dashboard (that I know of) but I also struggle to think of why one would want an artisanal dashboard when <https://docs.github.com/en/actions/use-cases-and-examples/de...> and <https://docs.gitlab.com/ee/ci/environments/index.html> exist in close proximity to the existing CI infrastructure. I guess if one is trying to be "CI agnostic" but my life experience is that trying to be CI agnostic leads to a lot of NIH which one cannot hire for and cannot take to the next job
While this is in the CI adjacent (and indeed I am a big dagger fan and certainly inspired by it), this predominantly lives in the CD realm instead.
In particular, it has helped us with something that I feel is missing in the GitOps space, which is the connective tissue between environments. Automating updates to app versions directly in repo and then bringing that altogether into a single dashboard where I can see what does my repo say the desired state of the world should be. Ultimately, we want to surface what the actual state is too.
We’ve hedged our bets a bit so far and left room for non GitOps CD to potentially slot in too. But not sure if we should just double down and be explicit and go hard on GitOps.
When you say a “why not…” you’re referring to like a Glu compared with X section right? That’s a good idea. I will add that!
