Dagger Functions | Hacker News Reader

Dagger Functions

dagger.io

24 pointsshykes5 comments

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)

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.

> What are Dagger Functions?

> Dagger Functions are a core feature of the Dagger Engine, which we are expanding and making available to all developers.

Yeah not great

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.

I'd pay them a dollar to stop using cowsay as their example, but it does eventually get to the point: https://docs.dagger.io/quickstart/562821/hello

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:

  # .gitlab-ci.yml
  example:
    extends: [.docker-dind-good-luck-lol]
    script:
    - dagger call -m github.com/example-co/our-awesome-step-in-our-language@v0.5

Reply on news.ycombinator.com