I don't want to yuck your yum, since it seems like this solved your problem for your crew. However, I always value launch posts like this which have a "why not ..." section, since (a) it helps folks who want to adopt your toy to understand its tradeoffs and know if they are the right tradeoffs for the adopter (b) it shows that the system was at least plausibly well designed and not filled with "oh, is that a thing?!" which requires abandoning it shortly after stumbling on real problems (I think of this as "The JavaScript Framework Lifecycle")
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
I appreciate you sharing your first interpretations! I get the impression it’s not that clear what this is. Trying to position what this is / figure out where we go with it is tricky/going to be a journey.
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!
I don't want to yuck your yum, since it seems like this solved your problem for your crew. However, I always value launch posts like this which have a "why not ..." section, since (a) it helps folks who want to adopt your toy to understand its tradeoffs and know if they are the right tradeoffs for the adopter (b) it shows that the system was at least plausibly well designed and not filled with "oh, is that a thing?!" which requires abandoning it shortly after stumbling on real problems (I think of this as "The JavaScript Framework Lifecycle")
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
I appreciate you sharing your first interpretations! I get the impression it’s not that clear what this is. Trying to position what this is / figure out where we go with it is tricky/going to be a journey.
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!