Dagger: a new way to build CI/CD pipelines

I'm in the same boat, but I do think there's a prospect of Dagger being a superior option in the long term, if...

1. They invest in building out their catalog of actions to compete with GitHub's. I maintain a few GitHub Actions and despite the GitHub catalog's depth, it's still lacking in many ways and GitHub don't appear to invest in it too much: a "maintainer fund" and creative poaching from Dagger could rapidly bring them up to par. A few million of their raise, well deployed, could crush GitHub's catalog.

2. They invest in tight integrations with platforms. GitHub Actions is great because of composability, yes, but also the deep integration with GitHub itself. Being able to run Dagger on GitHub Actions is one thing, but being able to leverage deployment environments cross-platform would be another.

3. GitHub Actions is great, I am a fan of it, I'll speak highly of it often, but the codebase... it is bad. If Dagger can build out a platform that competes with GitHub Actions on functionality, and it has a pleasant codebase, they'll make huge gains from community participation. Contributing to GitHub Actions is painful.

So, I agree with you today, but a year from now, I could see a very different situation and I am optimistic.

TLDR this basically looks like portable GitHub Actions + Workflows if I understand correctly.

I support the effort to build a platform-agnostic CI/CD pipeline solution, but I don't want it in the form of yet another platform. Rather it needs to be a protocol that any platform can tie in to. I'm especially wary since this is another VC-backed effort that will eventually need to be monetized in some shape or form.

Additionally, as someone else here has already mentioned, my mind first went to Dagger, the dependency injection tool (https://dagger.dev). That tool in particular was named as a play on DAG (directed acyclic graphs), whereas in this case I don't think it would apply since there may be instances where you'd want cycles in a pipeline.

On a whim, I clicked on "Trademark Guidelines" (https://dagger.io/trademark) and from that page alone I would recommend avoiding this based on the aggressive language used to try and claim ownership of generic words. According to their own language, it seems I'm violating their guidelines by writing this comment.

> Our Marks consist of the following registered, unregistered and/or pending trademarks, service marks and logos which are subject to change without notice: Dagger; Blocklayer; and other designs, logos or marks which may be referred to in your specific license agreement or otherwise.

> Blocklayer does not permit using any of our Marks ... to identify non-Blocklayer products, services or technology

Which would include Dagger, the dependency injection tool.

Other sections of note:

> Do Not Use As Nouns

(This one just reads amusingly to me, for some reason.)

> Do Not Create Composite Marks

This section seems to suggest that you can't use "dagger" in any shape or form, even as a smaller part of some other word or body of text.

> Websites And Domain Name Uses

>

> ... Any principal or secondary level domain name should not be identical to or virtually identical to any of our Marks.

>

> The website owner should not register any domain name containing our Marks and should not claim any trademark or similar proprietary rights in the domain name. For example, “daggertech.com”, “dagger-group.com”, “Meetdagger.com” are not allowed. Any violation of this policy may result in legal action.

>

> The website should otherwise comply with domain name registry policies and applicable laws regarding trademark infringement and dilution.

This would technically include dagger.dev, which again refers to the dependency injection tool.

---

Full disclaimer that I'm not a lawyer and there could be totally reasonable explanations for these provisions, but they certainly look scary to a layperson such as myself. All in all, the founders seem to be taking a pretty arrogant approach here, but it unfortunately seems to be a common one. I'm choosing not to support it, however.

---

EDIT: formatting

> 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 run on a native machine, or inside a container. Either way, building docker images is one of the most common actions performed by Dagger, and it is very well supported.