This is marketing copy, I think, and not great copy at that. Even after skimming it for 3 minutes, I still have no idea what it's about, other than that they're trying to sell a container control plane of some kind.
Dagger is an API exposed through GraphQL, offering specialized functions for constructing and executing containers. Imagine substituting Dockerfiles with GraphQL calls, and then the Dagger daemon executes the provided instructions. The outcome is a kind of "Turing complete" replacement for Dockerfiles.
The final aspect is that, typically, you wouldn't interact directly with the GraphQL API. Dagger provides wrappers for it in several languages.
Dagger 0.10 enables you to define and invoke your own functions, in addition to those already defined in the core Dagger API.
The initial purpose was to simplify the process of running the same task in any environment. For example, it allows you to replace the cumbersome YAML step definitions of CI/CD systems and effortlessly execute the same task both remotely and locally.
as best I can tell: It seems their innovation is that instead of having a GitHub Action in JavaScript as the reusable step in CI, one can build up company-specific "Dagger Actions" in any language the Dagger Engine supports, then invoke them in a versioned way that receives rich objects as parameters, ala PowerShell (e.g. not text, actual live objects)
# GHA way
jobs:
example:
steps:
- name: old way
uses: example/my-awesome-step@v5
# Dagger way
steps:
- name: Call Dagger Function
uses: dagger/dagger-for-github@v5
with:
version: "0.10.0"
verb: call
module: github.com/example-co/our-awesome-step-in-our-language@v0.5
and one may wonder, "but why?" and the theory is that unlike nektos/act which is a very, very skeletal implementation of GHA for local, dagger should(!) allow a local build step (or even GitLab CI, or Jenkins) that runs the same as GHA, promoting CI agnostic build pipelines:
This was previously "project zenith" and the point was to be able to make a module (that is a bunch of stuff running in a container) that's pluggable into a bigger ecosystem. I use Dagger, but I don't yet use this feature. (think modules, written in any supported language, that you can use in your build process)
5 comments
[ 2.8 ms ] story [ 25.6 ms ] thread> Dagger Functions are a core feature of the Dagger Engine, which we are expanding and making available to all developers.
Yeah not great
The final aspect is that, typically, you wouldn't interact directly with the GraphQL API. Dagger provides wrappers for it in several languages.
Dagger 0.10 enables you to define and invoke your own functions, in addition to those already defined in the core Dagger API.
The initial purpose was to simplify the process of running the same task in any environment. For example, it allows you to replace the cumbersome YAML step definitions of CI/CD systems and effortlessly execute the same task both remotely and locally.
as best I can tell: It seems their innovation is that instead of having a GitHub Action in JavaScript as the reusable step in CI, one can build up company-specific "Dagger Actions" in any language the Dagger Engine supports, then invoke them in a versioned way that receives rich objects as parameters, ala PowerShell (e.g. not text, actual live objects)
and one may wonder, "but why?" and the theory is that unlike nektos/act which is a very, very skeletal implementation of GHA for local, dagger should(!) allow a local build step (or even GitLab CI, or Jenkins) that runs the same as GHA, promoting CI agnostic build pipelines: