shykes

18 ms·

241.
by shykes 5y ago
> > Note: you won't need to configure caching though, because Dagger automatically caches all actions out of the box :) > Is this strictly because it's using Docker underneath and layers can be reused? Not exactly: we use
242.
by shykes 5y ago
Good question. No, we don't intend to replace the CI service. We think of CI as infrastructure, and there are plenty of great infrastructure providers out there. And you are absolutely correct that for Dagger to succeed, it has to re
243.
by shykes 5y ago
Yes, we use CUE as more than just a YAML replacement. In particular we use CUE references to construct the DAG and "compile" it to buildkit. And, yes, Dagger will gradually fill the missing values in the CUE tree during runtime. E
244.
by shykes 5y ago
Yes that is a good summary. It has other advantages beyond its portability - but that is the central feature. Also, importantly, it can run on Github Actions itself!
245.
by shykes 5y ago
The only dependency for running Dagger is buildkit - which itself requires a docker-compatible container runtime. This could be containerd, runc or of course Docker engine. If your environment can run Docker containers, it can run Dagger. T
246.
by shykes 5y ago
That is sadly often true today, but not inevitable! When you are overwhelmed with complexity, a natural defense mechanism is to restrict choice. But with better tooling, you can better manage and reduce complexity, which allows you to say &
247.
by shykes 5y ago
I know exactly what you mean. Earlier versions of Dagger actually took this "embedding" approach: any CUE configuration is a valid Dagger configuration, with an extra layer of annotation that describes how to make that configurati
248.
by shykes 5y ago
There will be an optional cloud service (not yet available). Its features will be based on requests from the community. Some problems just can't be solved with a command-line client. For example: visualization of your pipelines; a cent
249.
by shykes 5y ago
> Seems to assume that all CI/CD workflows work in a single container at a time pattern. Dagger runs your workflows as a DAG, where each node is an action running in its own container. The dependency graph is detected automatically,
250.
by shykes 5y ago
Yes, I believe that is a fair comparison. Earhly is more focused on builds, whereas Dagger has a wider scope: build, test, deployment, any part of a CI/CD pipeline really. But the overall philosophy is the same: run everything in conta
251.
by shykes 5y ago
Yes :) We rely entirely on buildkit ( https://github.com/moby/buildkit ) to run the pipelines (`dagger` itself acts as a "compiler" and buildkit client). So anything you can do with buildkit, works out of the b
252.
by shykes 5y ago
Thank you for the feedback! I referenced it in an issue here: https://github.com/dagger/dagger/issues/1946
253.
by shykes 5y ago
Fun fact, Crazy Max is the author of the Github Action for Dagger :) https://github.com/dagger/dagger-for-github
254.
by shykes 5y ago
> so does its worker run on a native machine, because we need to build docker images using CI/CD, which we can't do easily within a container? `dagger` is a client tool, which uses buildkit as its worker. Buildkit itself can ru
255.
by shykes 5y ago
To clarify, you can run Dagger on Gitlab today. It just requires some manual configuration that we would like to automate away, for convenience. We have only done this for Github so far, and would like to do it for more. We will look for a
256.
by shykes 5y ago
That's fair, it can be hard to find the right balance of high-level explanation and technical detail. We tried to solve this by tailoring different parts to different audiences: * The blog post is more high-level. It describes the very
257.
by shykes 5y ago
Sure, it's better for 3 reasons: 1. You can use the same pipelines in development and automation. Dagger runs on Jenkins, but it also runs on the developer's laptop. This solves a common problem which is drift between the automati
258.
by shykes 5y ago
One way or the other, you will have to write a declarative configuration describing which containers to run, and how to interconnect them. Then you'll want to add templating to that configuration, perhaps a schema verification tool, so
259.
by shykes 5y ago
Sorry about that. We'll fix it asap.
260.
by shykes 5y ago
We consider Dagger to be beta-quality. It definitely has bugs, and APIs are still moving, though we make a big effort to limit breaking changes, and help developers migrate when breaking changes do occur. We aim to be able to guarantee comp
261.
by shykes 5y ago
Yes :) You can write one last Jenkinsfile that runs Dagger, then do everything inside Dagger. Then you can run the exact same Dagger configuration on another CI system, or on your laptop. All you need is a Docker-compatible runtime (we run
262.
by shykes 5y ago
Hi everyone, I'm one of the co-founders of Dagger (and before that founder of Docker). This is a big day for us, it's our first time sharing something new since, you know... Docker. If you have any questions, I'll be happy to
263.
Docker founders launch Dagger, a new DevOps platform(techcrunch.com)
7 points by shykes 5y ago|0 comments
264.
Dagger: a new way to build CI/CD pipelines(dagger.io)
397 points by shykes 5y ago|259 comments
265.
by shykes 5y ago
If you’ve ever had to wrangle yaml configuration files… do yourself a favor and learn Cue. It’s still young and the website can seem intimidating; but it’s simpler than it looks, and the language is unbelievably powerful. There simply isn’t
266.
by shykes 8y ago
Too late for me, I already bought 3 of them at full price... I’m estimating that’s the reserve I need to hold out until Apple changes their mind and bring back this form factor.
267.
by shykes 8y ago
I don't understand this line of thinking. IBM has plenty of people contributing to open-source projects. I wouldn't be surprised if they contributed to etcd even before the acquisition. When it comes to their open-source track rec
268.
by shykes 9y ago
My thought exactly.
269.
by shykes 9y ago
This article makes it seem like drug companies alone are responsible for predatory pricing in US healthcare, with hospitals being somehow on the consumer's side of the issue. In reality US hospitals are just as guilty of predatory beha
270.
by shykes 9y ago
This is fantastic. I have been doing all my personal open-source work anonymously, and it requires a surprising amount of tooling to get it right. I will give gitmask a try.

More ›