shykes

18 ms·

181.
by shykes 3y ago
That’s how Dagger works. You use Dagger to make those building blocks cleaner, faster, and more portable. Then you can run them directly, or from your favorite CI configuration.
182.
by shykes 3y ago
Hi, Dagger co-founder here. Dagger is really just a streamlined implementation of two very common patterns: 1) Keeping your CI configuration as light and "dumb" as possible, by moving as much logic as possible into portable script
183.
Streamlining CI/CD Pipelines with Code(blog.matiaspan.dev)
73 points by shykes 3y ago|34 comments
184.
by shykes 3y ago
I’ll throw my hat into the ring… We are making dagger.io to solve this exact problem.
185.
by shykes 3y ago
I agree, as the maker as a tool that lets you program your CI with a real language instead of a terrible DSL, our first instinct was to bash YAML itself for cheap marketing points, but what you’re saying is exactly right: YAML is not perfec
186.
by shykes 3y ago
> I think I have a reasonable fear that `npm ci` just for the Dagger pipeline will hit multiple minutes, and then developers who expect linting and similar short-run jobs to finish within 30 seconds are going to wonder why they're
187.
by shykes 3y ago
Hi! Dagger co-founder here. I thought I’d share a few clarifying points - and acknowledge that we should explain certain aspects of Dagger’s design better, to avoid having to clarify in the first place! > you anyway need to run setup-no
188.
by shykes 3y ago
> Dagger devs have de facto abandoned that language entirely in favor of churning out SDKs for the most popular programming languages— all imperative, all Turing-complete, and all, imo, bad fits for the space. Disclaimer: I’m the CEO o
189.
MLOps with Hugging Face Spaces and Dagger(github.com)
4 points by shykes 3y ago|0 comments
190.
Exploring Firecracker MicroVMs for Multi-Tenant Dagger CI/CD Pipelines(felipecruz.es)
4 points by shykes 3y ago|0 comments
191.
by shykes 4y ago
> Someone from France is telling you that actually, it's really not that great... If there is one immutable truth about the French psyche, it’s that things are always “really not that great”. Source: I am French, and left France
192.
How we Release Dagger(dagger.io)
3 points by shykes 4y ago|0 comments
193.
Reproducible Builds with Dagger(dagger.io)
3 points by shykes 4y ago|0 comments
194.
How Dagger Uses Ruff(dagger.io)
3 points by shykes 4y ago|0 comments
195.
Why I Joined Dagger(dev.to)
2 points by shykes 4y ago|0 comments
196.
by shykes 4y ago
As the original creators of the Dockerfile, we take that as a compliment :) Our goal generally is not to replace Dockerfiles with Go. In most cases, that is not a desirable goal, for the reasons you listed. However, we do think you should r
197.
by shykes 4y ago
Dagger co-founder here. This bit is important: > Since Dagger can natively run Dockerfiles with full compatibility, it’s easy to wrap your existing Dockerfile in a Dagger pipeline, and gradually refactor it over time, without breaking y
198.
by shykes 4y ago
I am considering it. I prefer to not worry about hosting at all, but if I am forced to think about it, I would rather use a hosting provider that I’m already familiar with. If hosting my own server is too much work, or has other downsides I
199.
by shykes 4y ago
Dagger co-founder here. This API is foundational to Dagger's new architecture: it's what allows us to support so many different languages without losing the benefit of a unified engine. In fact our various SDKs are automatically g
200.
by shykes 4y ago
Hi everyone! This launch comes on the heels of our Go SDK and Python SDK launch. Our goal is to eventually allow any developer to create CI/CD pipelines in their favorite language, and run them anywhere. As usual, happy to answer any q
201.
by shykes 4y ago
You can absolutely test Dagger pipelines, in the same way you test the rest of your code. Just use the dagger library in your tests files, the way you would use any other library. It should work the way you expect.
202.
by shykes 4y ago
I agree, that would be very useful. We have been investigating the best way to deliver this. Probably a generator tool, that would take a dagger project as input, and produce a jenkins configuration as output. This of course could itself be
203.
by shykes 4y ago
I'd love to learn more! May I ask what your use case, and what you mean by "buildkit access"?
204.
by shykes 4y ago
Thanks for the kind words! > Running the same pipeline locally, there are ways to synthetically inject this, but there's no ready support in your framework yet for this (as ideally you'd have an 'authentication' para
205.
by shykes 4y ago
> I'm missing most is a nice UI above all that. How to present realtime and historic logs (and state) for multiple concurrent actions is still not as easy as I think it could be. We have plans to solve that :)
206.
by shykes 4y ago
> A) Why async in the user code? Is it really necessary? We support both sync and async mode. The Python ecosystem is in a state of flux at the moment between sync and async, so it seemed like the best approach to offer both and let de
207.
by shykes 4y ago
> Does it mean the sdk is making a round trip to the dagger API remotely somewhere, or is the round trip to a locally running docker container? The short answer, for now, is: "it's complicated" :) There's a detailed
208.
by shykes 4y ago
> What's the scope of this project? Is it meant to be closer to developers or do you see this being used in production? Dagger is meant for both development and production. Note that Dagger doesn't run your application itself
209.
by shykes 4y ago
> What's unclear to me from the article and video is how this can replace e.g. GitHub Actions. Their integration with e.g. PR status checks and the like is a must, of course. You guessed correctly: Dagger does not replace Github A
210.
by shykes 4y ago
Dagger remains a declarative DAG-based system. The trick is that you can control it with a (also declarative) API. This gives you the best of both worlds: a robust declarative environment to run your pipelines, accessible from your favorite

More ›