How is this different from buildkite
Dagger: a new way to build CI/CD pipelines
141–150 of 267 posts
Re: Dagger: a new way to build CI/CD pipelines
#142I'm not touching anything Docker anymore. Here's the scenario: you're the unfortunate soul who received the first M1 as a new employee, and nothing Docker-related works. Cue multi-arch builds; what a rotten mess. I spent more than a week figuring out the careful orchestration that any build involving `docker manifest` needs. If you aren't within the very fine line that buildx assumes, good luck pal. How long has `doc…
I can sympathize, but want to clarify that, although I did found Docker, I left 4 years ago. Dagger is not affiliated with Docker in any way.
Also: Dagger can integrate with Podman, Buildah and Cosign :)
Re: Dagger: a new way to build CI/CD pipelines
#143Earlier quoted context omitted.
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 containers. The choice of buildkit as a runtime is also a key similarity. One big difference is that we use CUE as a configuration language, and Earthly uses YAML. We have a lot of respect (…
Earthly doesn’t use YAML but a syntax which is similar to Dockerfile with dashes of Makefile. I’m finding it extremely pleasant to write.
I stand corrected! Earthly developers if you read this, I'm sorry for misremembering. I would correct my original post if I could.
Re: Dagger: a new way to build CI/CD pipelines
#144Earlier quoted context omitted.
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 containers. The choice of buildkit as a runtime is also a key similarity. One big difference is that we use CUE as a configuration language, and Earthly uses YAML. We have a lot of respect (…
Another *monster* difference is that Dagger is (at least currently) Apache 2: https://github.com/dagger/dagger/blob/v0.2.4/LICENSE but Earthly went with BSL: https://github.com/earthly/earthly/blob/v0.6.12/LICENSE That means I'm more likely to submit bugs and patches to Dagger, and I won't touch Earthly
I can't speak to Earthly's choice of license (and am not familiar with BSL). But can confirm that we have no intention of changing licenses, and if we did, it would be for another OSI-approved license.
Our monetization model follows the same fundamentals as Red Hat before us: open code, strictly enforced trademark rules. "You can modify, use and redistribute the code at will. If you distribute a modified version, please call it something else."
Re: Dagger: a new way to build CI/CD pipelines
#145Earlier quoted context omitted.
Dagger is already a popular dependency injection framework, so why choose a name that will be confusing to people who will likely use both of these frameworks in their projects?
And the reason they're both called Dagger is as a play on using a DAG, directed acyclic graph, to model dependencies. Stealing that wittiness and pretending it's their own is pathetic.
I believe the required creativity for that is not that high as it doesn’t seem too far fetched. I’d rather call it a piece of convergent evolution.
Re: Dagger: a new way to build CI/CD pipelines
#146I’m highly jealous of teams that can containerize all their build tools. If you deal with proprietary toolchains that are tens of gigabytes (Windows WDK, Xilinx Vivado/Vitis) it’s just untenable, and that’s before even mentioning licensing. Even Azure doesn’t have a great solution for WDK development. It’s hard to feel like we’re not being left behind. Bind mounting the tools into the container is an option but at th…
You can add Apple toolchains to that list also
preach
Re: Dagger: a new way to build CI/CD pipelines
#147Ci/CD is transforming right now but I don't think dagger is solving those things or I don't understand it well enough yet.
GitHub action is a game changer. CICD finally has a proper UI were it belongs: on the repository.
GitHub actions are also much easier than gitlab runner. The basic actions are great and probably solve 90% of all normal use cases.
Then we/I see a big trend of going away from self build pipelines. Provide Standard Features through convention over configuration: the docker image build action checks if it need to run on the pipeline and runs isolated by default.
The build packs are providing something like this but they are to clumsy/complex.
Then you have the real issue no one is solving:
- fast sync between stages and builds. 1 gb of source code, maven cache etc. Still need effort to do it fast. Preferable a filesystem which is fast and allows to share snapshots you can mount ober the network (it's not a big issue but puts a latency limit on how fast you can provide build results and I like it fast)
- standard building blocks with retry mechanism. When a 3h build fails, restarting is annoying like hell. Pipelines have very little resilience.
- unified CICD output: lots of plugins support Jenkins Replacing Jenkins needs a new UI (GitHub has it now) which still is not unified. There is a thing going on to univy on GitHub through GitHub checks.
I think in the next few years GitHub will have solved those issues for us. They do exactly what you are looking for. Would love to work with them.
They even now inject the repository secret for you. They are slow (hello personal access token alternative we are waiting...) But steady.
Btw. Before someone says gitlab: the Auto DevOps thing was shitty and bad supported. A default case with java and postgres was/is not fixed for 3 years.
And those vulnerabilities. The last few years? Nope nope nope.
Re: Dagger: a new way to build CI/CD pipelines
#148Earlier quoted context omitted.
The language is CUE, which I think will see mass adoption in config / DevOps in the coming years. So regardless what you think of the language today, it is likely to become important and part of your like in the not too distant future. https://cuelang.org | https://cuetorials.com Dagger builds on top of CUE and the (DAG) flow engine therein
That's great context. That should be added to that doc link right at the top, it would have me feel much more safe about investing the time to learn it!
CUE has good pedigree, the creator Marcel wrote the prototype for Borg (k8s), worked on both Google config languages, and worked on the Go team. CUE is how he thinks those Google config languages should have been designed.
Re: Dagger: a new way to build CI/CD pipelines
#149Earlier quoted context omitted.
The language is CUE, which I think will see mass adoption in config / DevOps in the coming years. So regardless what you think of the language today, it is likely to become important and part of your like in the not too distant future. https://cuelang.org | https://cuetorials.com Dagger builds on top of CUE and the (DAG) flow engine therein
Oh wow, the validating yaml example on the front page looks super useful. Might try and play with this over the next few weeks!
Once CUE clicked for me, there was no going back
Re: Dagger: a new way to build CI/CD pipelines
#150Earlier quoted context omitted.
> We will not rely on unusual licences to restrict competitors from running Dagger as a service. Your "Trademark Guidelines" appear to contradict you: > Third-party products may not use the Marks to suggest compatibility or interoperability with our platform. For example, the claims “xxx is compatible with Dagger”, “xxx can run your Dagger configurations”, are not allowed. > but you have to build your own brand, and…
> > We will not rely on unusual licences to restrict competitors from running Dagger as a service. > Your "Trademark Guidelines" appear to contradict you: They do not. Software licenses and trademark guidelines are two different things. Some commercial open-source vendors have changed their licenses to restrict use of the software in various ways - typically to limit competition from large cloud providers. We don't d…
> > > We will not rely on unusual licences to restrict competitors from running Dagger as a service.
> > Your "Trademark Guidelines" appear to contradict you:
> They do not. Software licenses and trademark guidelines are two different things. Some commercial open-source vendors have changed their licenses to restrict use of the software in various ways - typically to limit competition from large cloud providers. We don't do that, and have no intention to. Our license is OSI-approved and we intend to keep it that way. That is what I am referring to.
I'm glad the product is open source, but that provision isn't in the context of source code, it is a top-level item listed on that page. That's why I interpreted "unusual licences" to generally mean a sort of "legal acrobatics".
When you're threatening people with legal action you need to be clear, and right now the text on that page is not, according to what you're saying here. I doubt many people are going to be searching Hacker News comments for the true intent behind these guidelines.
> I disagree. Dagger has existed in private beta for over a year, thousands of engineers have been given access, and I can't remember a single instance of any of them being confused by the name. We have registered the trademark, and nobody has raised an issue.
I don't think that really addresses the point. Dagger (as started under Square) is nearly ten years old, and Google's 2.0 fork is from 2016. It's used by thousands of published Maven artifacts, countless applications, and tens of thousands of developers (at least). This is the first time I've heard of your project, but that's bound to happen in tech. Whether you registered it or not without complaint doesn't much matter either, the issue is being raised here, now that you've publicly launched.