4 ms·
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 https://doc
by mdaniel 3y ago
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 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