Earlier quoted context omitted.
Do you have any more details on using Cue with GHA? I've also looked at Dagger and been quite disappointed with it (and their terrible documentation).
When I got started it was much more difficult as you had to do a lot of manual work to get things started, and you really had to believe the promises that CUE offered (which I did...), but nowadays they've made so many steps in the right direction that getting something going is far quicker! Here are a few links to whet your appetite: - https://cue.dev/docs/getting-started-with-github-actions-cue... - https://cue.dev…
Dagger: Define software delivery workflows and dev environments
21–30 of 78 posts
Re: Dagger: Define software delivery workflows and dev environments
#22Dagger was something I looked into two or so years ago before they got consumed by the LLM and AI agent hype, and while the promise of being able to run the exact CI workflows locally seemed excellent, it seemed that there's basically no way be a Dagger user without buying into their Dagger Cloud product. I ended up opting for CUE and GitHub Actions, and I'm glad I did as it made everything much, much simpler.
Can you explain/link to why you can't really use this without their cloud product? I'm not seeing anything at a glance, and this looks useful for a project of mine, but I don't want to be trapped by limitations that I only find out about after putting in weeks of work
re: the cloud specifically see these GitHub issues:
https://github.com/dagger/dagger/issues/6486
https://github.com/dagger/dagger/issues/8004
Basically if you want consistently fast cached builds it's a PITA and/or not possible without the cloud product, depending on how you set things up. We do run it self-hosted though, YMMV.
Re: Dagger: Define software delivery workflows and dev environments
#23Earlier quoted context omitted.
No, it's code based CI/CD not a build system.
I'd say it's somewhere in between. Sure it's marketed in the CI space, but to me the selling point of Dagger is not so much "write your GitHub workflows/GitLab CI in JavaScript" but "local exec, sandboxing, determinism, and fine-grained (remote) caching for mere mortals". So comparing it to Bazel/Buck2 is reasonable.
Re: Dagger: Define software delivery workflows and dev environments
#24What else could be used to abstract away your CICD from the launcher (Jenkins, Argo Workflows, GitHub Actions, etc.)?
Re: Dagger: Define software delivery workflows and dev environments
#25Re: Dagger: Define software delivery workflows and dev environments
#26They don't seem to have jumped for AI hype (yet?)...
Re: Dagger: Define software delivery workflows and dev environments
#27Curious if anyone in the thread has / is using windmill? They don't seem to have jumped for AI hype (yet?)... https://www.windmill.dev/
Re: Dagger: Define software delivery workflows and dev environments
#28This looks interesting but I’m trying to understand it in more layman’s terms. Is it more about providing abstractions for llms to work within to do things?
Re: Dagger: Define software delivery workflows and dev environments
#29I think a more interesting point of comparison is the Claude Code Github Action, Co-Pilot code reviews, etc.
Re: Dagger: Define software delivery workflows and dev environments
#30Curious if anyone in the thread has / is using windmill? They don't seem to have jumped for AI hype (yet?)... https://www.windmill.dev/