dagger / dagger-for-github

GitHub Action for Dagger

GitHub action to run Dagger

Usage Examples

dagger call (default)

- name: Hello
  uses: dagger/dagger-for-github@v5
  with:
    verb: call 
    module: github.com/shykes/daggerverse/hello
    args: with-greeting --greeting Hola with-name --name Jeremy message
    cloud-token: ${{ secrets.DAGGER_CLOUD_TOKEN }}

dagger run

- name: Integration Test
  uses: dagger/dagger-for-github@v5
  with:
    workdir: db-service
    verb: run
    args: node build.js
    cloud-token: ${{ secrets.DAGGER_CLOUD_TOKEN }}
    version: "0.11.1"

Staying in sync with the latest version

By setting the version to latest, this action will install the latest version of Dagger.

All with: input parameter options

Key	Description	Required	Default
version	Dagger Version	false	'0.11.1'
dagger-flags	Dagger CLI Flags	false	'--progress plain'
verb	CLI verb (call, run, download, up, functions, shell, query)	false	'call'
workdir	The working directory in which to run the Dagger CLI	false	'.'
cloud-token	Dagger Cloud Token	false	''
module	Dagger module to call. Local or Git	false	''
args	Arguments to pass to CLI	false	''
engine-stop	Whether to stop the Dagger Engine after this run	false	'true'

dagger-for-github's Issues

:shipit: Release `v5` to GH Actions Marketplace

Done! https://github.com/marketplace/actions/dagger-for-github
Tested: https://github.com/jpadams/test-new-action/actions/runs/6869662549/job/18682906959

🧪 Handle `version` inputs that start with `v`

curl -sL https://dl.dagger.io/dagger/install.sh 2>/dev/null | \
        DAGGER_VERSION='v0.9.2' sh
sh debug downloading files into /var/folders/s4/xyj9q5ps2ys3rc9nsps1v20m0000gn/T/tmp.tTShNB7AUU
sh debug http_download https://dl.dagger.io/dagger/releases/v0.9.2/dagger_vv0.9.2_darwin_arm64.tar.gz
sh debug http_download_curl received HTTP status 403

errors out because of extra v. Could be solved be removing the v here or could also be fixed upstream in the installer script, which might be better.

Add cache option to Dagger action

When dagger/dagger#1839 will be merged, we should update this action to supports cache option.

In a discussion with @aluzzardi, we talk about the following shape:

        name: Dagger
        uses: dagger/dagger-for-github@v2
        with:
          cache: true // New option
          cache-scope: example // Scope of the cache
          args: do test

That would add

• cache: enable or disable GitHub cache for dagger | set to false by default?
• cache-scope: explicit cache scope, useful to do not override existing cache from other action | set to dagger by default?

Question
Should we also add mode option?

Useful links

• Buildkit GitHub cache

Dagger `install-only` doesn't persist `age-key`

Problem

Several users have felt the need to use dagger with the install-only option for 2 reasons mainly:

1. They need to retrieve the context of the commit / PR
2. Their internal policy restricts the use of encrypted files containing secrets, regardless the security level of the encrypted file.

For the second case, no issue arises

People just push without a .dagger folder and literally add the inputs/secrets in the GitHub workflow:

# This is a basic workflow to help you get started with Actions

name: Dagger PR test

# Controls when the workflow will run
on:
  # Triggers the workflow on a pull request event
  pull_request:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "dagger"
  dagger:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      - name: Install Dagger
        uses: dagger/dagger-action@v1
        with:
          install-only: true
          
      #- name: Show Dagger version
        #run: dagger version
        
      - name: Setup dagger environment "myenv"
        run: |
          dagger init
          dagger new myenv -p ./myenv
        
      - name: Pass PR number to Dagger
        run: dagger input text prID ${{github.event.number}} -e myenv
        
      - name: List Dagger inputs
        run: dagger input list -e myenv
        
      - name: Dagger up!
        run: dagger up -e myenv
        
      - name: List Dagger outputs
        run: dagger output list -e myenv

But, some people want to retrieve part of the Github context AND store their secrets in the sops file:

jobs:
  test_ci:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Install Dagger
        uses: dagger/dagger-action@v1
        with:
          age-key: ${{ secrets.DAGGER_AGE_KEY }}
          install-only: true

      - name: Pass Commit SHA to Dagger
        run: dagger input text githubCommitSha ${{github.sha}}

      - name: Dagger up!
        run: dagger up

The above code doesn't work, dagger doesn't find the sops key

Current Solution

After some debug, I found a way to make it work. It seems a little weird because the second time we added an input, the sops key gets found.

name: Dagger PR test

# Controls when the workflow will run
on:
  # Triggers the workflow on a pull request event
  push:
  pull_request:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "dagger"
  dagger:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      - name: Install Dagger
        uses: dagger/dagger-action@v1
        with:
          install-only: true

      - name: Pass commit sha
        uses: dagger/dagger-action@v1
        with:
          age-key: ${{ secrets.DAGGER_AGE_KEY }}
          args: input text githubCommitSha ${{github.sha}}

      - name: Dagger new input
        run: dagger input text githubCommitNumber "ok"

      - name: Dagger up!
        run: dagger up

`The save-state command is deprecated` warnings

What is the issue?

We started receiving deprecation warnings related to the use of save-state command.

Log output

> Run dagger/dagger-for-github@v3
  with:
    cmds: do build
  
    version: latest
    workdir: .
    install-only: false
    cleanup: true
  env:
    DAGGER_LOG_FORMAT: plain
    DAGGER_CACHE_BASE: dagger-ci-build
    DAGGER_CACHE_TO: type=gha,mode=max,scope=dagger-ci-build-245
    DAGGER_CACHE_FROM: type=gha,scope=dagger-ci-build-dev type=gha,scope=dagger-ci-build-245
Warning: The `save-state` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
> Download and install Dagger
  Downloading https://dl.dagger.io/dagger/releases/0.2.36/dagger_v0.2.36_linux_amd64.tar.gz
  Extracting Dagger
  /usr/bin/tar xz --warning=no-unknown-keyword --overwrite -C /home/runner/work/_temp/a762fb16-00f2-4c49-a05c-5fefeb38bc53 -f /home/runner/work/_temp/a7863c53-325e-4e39-9601-af41b7eb7b0f
Warning: The `save-state` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

Steps to reproduce

Run any workflow...

Dagger version

dagger 0.2.36 (linux/amd64)

OS version

Ubuntu 20.04.5 LTS

Run development version of dagger?

My plan requires a patched version of dagger. I want to run it in a github workflow, but since it runs the latest official release by default (currently 0.2.0), my patch is not included. How can I configure dagger-for-github to run my patched version of dagger?

a way to run `dagger project update` before `dagger do`

What are you trying to do?

have the action install cue deps for me

Why is this important to you?

I think it would be better if this action could install deps through a flag because I don't wont to check in dagger deps ATM

How are you currently working around this?

using install-only and running dagger project update before dagger do

Upgrade node version to Node16

As discussed with @crazy-max, at the end of the month, the hosted github runners will run with node16 by default. However, we are currently using Node12. This may imply some breaking changes that we should take into consideration.

Ref: https://github.blog/changelog/2021-12-10-github-actions-github-hosted-runners-now-run-node-js-16-by-default/

🐞 Engine stop is not called when the pipeline fails

What is the issue?

When the Dagger command fails for any reason, engine stop is not called.

The GitHub snippet in the documentation has an added condition to make sure engine stop runs even if the command before it fails:

      - name: Stop Engine
        run: docker stop -t 300 $(docker ps --filter name="dagger-engine-*" -q)
        if: always()

Dagger version

dagger v0.9.7 (registry.dagger.io/engine) darwin/arm64

Steps to reproduce

No response

Log output

No response

💅 Beautify the README

Make it beautiful for display on GH Marketplace

• text formatting / tables (if needed)
• relevant images
• logo

Rollback breakage caused by Dagger CLI 0.3 release

Problem

We recently released a new Dagger CLI, version 0.3, which is a hard breaking change from 0.2. There is a migration path in preparation (using a new CLI called dagger-cue which is drop-in compatible with 0.2), that was meant to be rolled out soon.

But we accidentally broke users of the current github action now, without warning, by auto-updating this action to dagger 0.3. This should be immediately reversed regardless of future migration plans.

Solution

Change the latest version of this action @v3 to pin to dagger 0.2, instead of latest.

This should resolve the immediate issue for users of the Github Action, and allow us to finish planning a proper migration path.

Thank you @fredleger for alerting us and we apologize for the poor experience!

Issue with Action dependencies (Vulnerabilities)

Hi folks,

An internal user requested us to on board this action so we ran it through some security checks, like forking it and enabling Dependabot. Dependabot found 52 issues in vulnerable dependencies, of which 6 are critical!

These might not be miss-usable by a caller of the action, but maybe you want to enable Dependabot and have it update those dependencies as well (I see it is in use for updating the Actions that are in use). as a best practice

Align versioning of dagger-for-github with dagger engine?

It seems that dagger-for-github has its own versioning: v1, v2, etc. I understand how this makes sense (it is its own software, makes sense to have its own versioning schema). But from the point of view of a Dagger user, I find it confusing because I only care about version of Dagger. How do I choose the right version of dagger-for-github? I might have to look up a version mapping...

it would be great if we could change the versioning of dagger-for-github so that it aligns with the versioning of dagger (ie. version 0.2 -> 0.2). Thoughts?

🐞 Doesn't print Dagger Cloud URL in GitHub Actions output

What is the issue?

Sends run to Dagger Cloud when secret DAGGER_CLOUD_TOKEN is provided, but doesn't print the Dagger Cloud url in the GitHub Actions output.
https://dagger.cloud/runs/b71383bb-a0f8-41af-b0d0-b553bd2f0ff1

Log output

No response

Steps to reproduce

No response

SDK version

Zenith, Dagger Call

OS version

From GH Actions

Update to use `dagger-cue` when released

Rename `dagger-action` to something less confusing

Problem

From the point of view of a Github Actions user, "dagger-action" makes perfect sense. But from the point of view of the Dagger community, it is confusing: is it a product called "action" by Dagger? Is it a way to perform an action in Dagger? Is it a clone of Github Actions by Dagger?

Solution

After discussion: the most pragmatic solution seems to be renaming this repo to dagger-for-github.

Alternative options

The following options were discussed:

1. Borrowing from Docker's edition model: dagger-for-github
2. Another variation on the edition model: dagger-on-github
3. Minimalist variatin: dagger-github
4. Same idea but more specific: dagger-gha

My preference right now is option 1: dagger-for-github. Simply because the format of "Docker for Mac", "Github for Mac" (fun fact: this is the inspiration for D4M :) is familiar to many developers.

✨ Support latest as the default option for the version input

What are you trying to do?

I want to stay in sync with the latest version of Dagger while using the GitHub action. However, I have to explicitly set the version to '', which isn't a great developer experience. The version input should default to latest and reflect this in the script and documentation.

Many other GitHub actions use this approach.

Why is this important to you?

Keeping in sync requires manual updates of my GitHub workflows or setting the version to ''. If I am to be explicit, I would prefer to put the version as latest within my workflows.

How are you currently working around this?

I have to manually update my workflows with the version of Dagger that I want.

🐞 ERR actions.deploy._build._dag."0"._dag."0"._op

What is the issue?

I'm trying to run the todoapp example in github ci using the guides example. I have a Netlify Token setup as a Actions secret. However, dagger returns a strange error during the deploy phase.

Why is this important to you?

I want to understand dagger and get it working with a simple example.

How are you currently working around this?

I found no workaround for this problem.

Log output

Run cd pkg/universe.dagger.io/examples/todoapp
time="2022-04-10T15:52:49Z" level=warning msg="commandConn.CloseWrite: commandconn: failed to wait: signal: terminated"
time="2022-04-10T15:52:49Z" level=warning msg="commandConn.CloseRead: commandconn: failed to wait: signal: terminated"
time="2022-04-10T15:52:49Z" level=warning msg="commandConn.CloseWrite: commandconn: failed to wait: signal: terminated"
3:52PM INF actions.deploy.container.script._load | computing
3:52PM INF client.filesystem."./".read | computing
3:52PM INF actions.test.script._write | computing
3:52PM INF actions.build.run.script._write | computing
3:52PM INF actions.deploy._build._dag."0"._dag."0"._op | computing
3:52PM ERR actions.deploy._build._dag."0"._dag."0"._op | failed: actions.deploy._build._dag."0"._dag."0"._op.source: undefined field: #Ref:
/home/runner/work/dagger/dagger/pkg/universe.dagger.io/docker/image.cue:23:14
duration=0s
3:52PM INF actions.deps._dag."2".script._write | computing
3:52PM ERR actions.deps._dag."2".script._write | canceled duration=0s
3:52PM ERR actions.deploy.container.script._load | canceled duration=0s
3:52PM ERR actions.test.script._write | canceled duration=0s
3:52PM ERR actions.build.run.script._write | canceled duration=0s
3:52PM INF client.env | computing
3:52PM INF client.env | completed duration=0s
3:52PM INF actions.deps._dag."0"._dag."0"._op | computing
3:52PM ERR actions.deps._dag."0"._dag."0"._op | failed: actions.deps._dag."0"._dag."0"._op.source: undefined field: #Ref:
/home/runner/work/dagger/dagger/pkg/universe.dagger.io/docker/image.cue:23:14
duration=0s
3:52PM ERR client.filesystem."./".read | canceled duration=0s
3:52PM FTL system | failed to execute plan: task failed: actions.deploy._build._dag."0"._dag."0"._op: actions.deploy._build._dag."0"._dag."0"._op.source: undefined field: #Ref:
/home/runner/work/dagger/dagger/pkg/universe.dagger.io/docker/image.cue:23:14

Error: Process completed with exit code 1.

Steps to reproduce

Here's the commit and workflow being run. My repository is basically the dagger repo minus the original workflows (I only have 1).

https://github.com/ivorscott/dagger/blob/2db6e572f65cdd0f2dac67eeb7044b05c1617b56/.github/workflows/todoapp.yml

Dagger version

0.2.5

OS version

macOS 12.13.1

📖 Improve documentation in the `README.md`

• more examples: have a dagger call and a dagger run example
• links to docs: no links yet...
• useful diagrams: none yet
• table of input options: done!

https://github.com/dagger/dagger-for-github/blob/ea5581fc7d79ae81db8c18029cbc76d3f45cf1ea/README.md

🐞 default working directory is not honored

What is the issue?

This action is not using the working directory when it is present.

Dagger version

dagger 0.10.2

Steps to reproduce

Create a workflow that uses a default directory:

name: Unit Tests

on:
  workflow_call:

jobs:
  test:
    defaults:
      run:
       # WORKING DIRECTORY HERE
        working-directory: dev/dagger
    runs-on: ubuntu-latest
    timeout-minutes: 30
    steps:
      - name: Checkout Project
        uses: actions/checkout@v3

      - name: Setup Node
        uses: actions/setup-node@v3

      - name: Install Dependencies
        run: npm install

      - name: Run Tests
        uses: dagger/dagger-for-github@v5
        with:
          version: '0.10.2'
          verb: run
          args: node --loader ts-node/esm src/unit-tests.mts

In order to work around this issue, you must re-specify the working directory:

...
      - name: Run Tests
        uses: dagger/dagger-for-github@v5
        with:
        # DUPLICATE CONFIG
         workDir: dev/dagger
          version: '0.10.2'
          verb: run
          args: node --loader ts-node/esm src/unit-tests.mts

Log output

No response

uses: dagger/dagger

I know we have already discussed naming and have already renamed this repo… I apologize for re-opening this topic but: are we sure we can’t just pick the name “dagger” for the action? When we first discussed this option, the answer was “not possible because dagger/dagger is already taken by the dagger repo itself”. But… couldn’t we move the action’s source to that repo? I guess we would have a top-level action.yaml file and other mild nuisance. But in exchange, everyone gets to write uses: dagger/dagger in their workflows? That DX improvement seems worth it to me :)

What am I missing?

Licence listed as MIT, but attached one is Apache License 2.0

What is the issue?

Main README (https://github.com/dagger/dagger-for-github/blob/main/README.md) indicates that license is MIT, while the attached one is Apache (https://github.com/dagger/dagger-for-github/blob/main/LICENSE).

Move `dagger` binary to `dagger-cue`

depends on:

• dagger/dagger#4069

The CUE SDK has been moved to dagger-cue recently
https://docs.dagger.io/sdk/cue/526369/install

Self hosted runners - ARC

What is the issue?

The issue I'd like to log, just more FYI, is that it seems that you cannot run the GitHub Dagger action, out of the box, with self hosted runners, on Kubernetes. I installed the ARC for GitHub, with Helm, with the quick-start guide. (With Helm, this was actually quite easy to install). I managed to register some runners, and most of the workflows just run fine. For reference, workflows that used the "docker/[email protected]", did work right away.

Dagger version

dagger v0.9.3

Steps to reproduce

Problem and Solution (1)

The following script works fine with GitHub runners but not with ARC:

name: 40_dagger_demo.yaml
permissions:
  contents: read
  packages: write
on:
  push:
    branches:
      - main
    paths:
      - 'apps/demo/**’
      - '.github/workflows/dagger_demo.yaml'
concurrency:
  group: ${{ github.ref }}-${{ github.workflow }}
  cancel-in-progress: true
jobs:
  build:
    name: build
    # runs-on: ubuntu-latest
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v3
      - name: '* Install dagger-io'
        run: pip install dagger-io
      - name: '* Run Dagger pipeline'
        uses: dagger/dagger-for-github@v5
        with:
          workdir: apps/demo
          verb: run
          args: python main.py "${{ secrets.DAGGER_KEY }}" github_username
          version: "0.9.3"

Solution

This is my workaround for the moment!! 😄 :

    steps:
      - name: '* Setup python'
        uses: actions/setup-python@v5
        with:
          python-version: 'pypy3.10'
      - name: '* Check out the repo'
        uses: actions/checkout@v4
      - name: '* Install manual'
        run: pip install anyio dagger-io==0.9.3
      - name: '* Run Dagger Pipeline'
        run: cd $GITHUB_WORKSPACE/apps/demo/ && python main.py "${{ secrets.DAGGER_KEY }}" github_username

Another varation that still does not work (2)

I also tried another variation, based on a suggestion from @marcosnils!
This still produces another error:

name: 40_dagger_demo.yaml
permissions:
  contents: read
  packages: write
on:
  push:
    branches:
      - main
    paths:
      - 'apps/demo/**'
      - '.github/workflows/40_dagger_demo.yaml'
concurrency:
  group: ${{ github.ref }}-${{ github.workflow }}
  cancel-in-progress: true
jobs:
  build:
    name: build
    # ---
    # runs-on: ubuntu-latest
    # ---
    runs-on: self-hosted
    steps:
      - name: '* Setup python'
        uses: actions/setup-python@v5
        with:
          python-version: 'pypy3.10'
      - name: '* Check out the repo'
        uses: actions/checkout@v4
      - name: '* Run Dagger pipeline'
        uses: dagger/dagger-for-github@v5
        with:
          workdir: apps/demo
          verb: run
          args: python main.py "${{ secrets.DAGGER_KEY }}" github_username
          version: "0.9.3"

Log output

No response

✨ Add parameter for different download location of the Dagger binaries

What are you trying to do?

We want to use this action on our GitHub Enterprise Server + self-hosted runners, and for security reasons we cannot let the runners download binaries from the internet. We can run security checks on them and store them inside of Artifactory.

For that purpose, we would like an extra parameter that we can pass in to download the Dagger binaries from. If you want, I can build it into a PR as well. That way we can override the default [location](https://github.com/dagger/dagger-for-github/blob/23fd2f48d13687b11cacd88aaf2082205e725bc3/src/dagger.ts#L11] if we need to (no param value == use default url).

Why is this important to you?

Without this feature, our users cannot use Dagger with this action, and have to do everything themselves. We've had the request twice now, so they would really like to use it :-).

How are you currently working around this?

We could create our own version of the action and download it from Artifactory ourselves, but I'd rather update functionality in the upstream repo and improve the world a little bit :-).

Should gracefully handle script that is not a Dagger pipeline

          > ## Another varation that still does not work (2)

this seemed to work, it's the docker stop part that failed after running the pipeline since it seems like the dagger engine wasn't started. @alex9fredericks could it be possible that the python main.py is not currently running a dagger pipeline in this case?

In any case we should handle this gracefully also.

Originally posted by @marcosnils in #106 (comment)

🐞 CI is failing when we use `--with` in args

What is the issue?

I have a small pipeline that build & push images in docker hub, I tested it locally and it worked fine but when i try to use it in CI it is failing

CI action will convert the command from
dagger do build -l debug --log-format plain --with 'actions: params: image: tag: "v0.2.0"' to /opt/hostedtoolcache/dagger/0.2.4/x64/dagger do build -l debug --log-format plain --with 'actions: params: image: tag: v0.2.0' --log-format plain

And that's wrong if you add double quotes to tag then it will work fine.

Log output

Steps to reproduce

Build Failure: https://github.com/evalsocket/dagger-flyte/runs/5816670062?check_suite_focus=true#step:4:1

Successful Build: https://github.com/evalsocket/dagger-flyte/runs/5816717792?check_suite_focus=true#step:4:1

Dagger version

v0.2.4

OS version

MacOs 12.2.1

🧪 Add tests to this repo to exercise the action

Example mentioned here: #98 (comment)

dagger-for-github@v3 is not working.

What is the issue?

dagger-for-github@v3, which was working until yesterday, has stopped working today.

Details:

I used dagger-for-github@v3.
The files downloaded in Action had changed.
when it was working until yesterday: https://dl.dagger.io/dagger/releases/0.2.36/dagger_v0.2.36_linux_amd64.tar.gz
when it failed today: https://dl.dagger.io/dagger/releases/0.3.12/dagger_v0.3.12_linux_amd64.tar.gz

For dagger-for-github@v3, the correct move appears to be to download the 0.2 series, and for dagger-for-github@v4 series, download the 0.3 series.
By the way, if I specify dagger-for-github@v4 in GitHub Action, I got an error saying it doesn't exist, so I'm guessing that you probably got the release wrong somehow.

Log output

project init
  /opt/hostedtoolcache/dagger/0.3.12/x64/dagger project init
  Error: unknown command "project" for "dagger"
  Run 'dagger --help' for usage.

Steps to reproduce

Execute github action with follow job.

jobs:
  build:
    runs-on: [self-hosted, Linux, X64]
    services:
      ...
    steps: 
      - name: Checkout
        uses: actions/checkout@v3
      - name: Prepare dagger and test environment
        uses: dagger/dagger-for-github@v3
        with:
          cmds: |
            project init

SDK version

OS version

🐞 shell error when using multi-line yaml

What is the issue?

Given the following config:
https://github.com/lukemarsden/test-dagger-actions/blob/c0e90ddf436947e4c6639fd95e2c491095f87ff5/.github/workflows/docker-publish.yml

In particular,

      - name: Dagger Build & Push
        uses: dagger/dagger-for-github@v5
        with:
          version: "0.11.0"
          verb: call
          args: |
            build-and-push \
            --registry=$DOCKER_REGISTRY \
            --image-name=$DOCKER_IMAGE_NAME \
            --username=$DOCKER_USERNAME \
            --password=env:DOCKER_PASSWORD
        env:
          DOCKER_REGISTRY: ${{ env.REGISTRY }}
          DOCKER_IMAGE_NAME: ${{ env.IMAGE_NAME }}
          DOCKER_USERNAME: ${{ github.actor }}
          DOCKER_PASSWORD: ${{ secrets.GITHUB_TOKEN }}

When using the multi-line string args: |, I suppose the string ends up including the trailing newline at the end, which results in the following error: https://github.com/lukemarsden/test-dagger-actions/actions/runs/8630455004/job/23656748756

In particular:

Run cd . && { \
  cd . && { \
  DAGGER_CLOUD_TOKEN= \
  dagger \
  --progress plain \
  call \
  ${INPUT_MODULE:+-m $INPUT_MODULE} \
  build-and-push \
  --registry=$DOCKER_REGISTRY \
  --image-name=$DOCKER_IMAGE_NAME \
  --username=$DOCKER_USERNAME \
  --***
  ; }
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    REGISTRY: ghcr.io
    IMAGE_NAME: lukemarsden/test-dagger-actions
    DOCKER_REGISTRY: ghcr.io
    DOCKER_IMAGE_NAME: lukemarsden/test-dagger-actions
    DOCKER_USERNAME: lukemarsden
    DOCKER_PASSWORD: ***
    INPUT_MODULE: 
/home/runner/work/_temp/18dc8cb9-bd6c-4e31-adb8-b2[96](https://github.com/lukemarsden/test-dagger-actions/actions/runs/8630455004/job/23656748756#step:3:98)01d09f1c.sh: line 12: syntax error near unexpected token `;'
Error: Process completed with exit code 2.

Switching to single line style, like:

          args: build-and-push --registry=$DOCKER_REGISTRY --image-name=$DOCKER_IMAGE_NAME --username=$DOCKER_USERNAME --password=env:DOCKER_PASSWORD --build-context .

fixes the issue, but of course is less readable

Dagger version

dagger v0.11.0 (registry.dagger.io/engine) darwin/arm64

Steps to reproduce

Run the above config

Log output

See above

Dogfeed action with Dagger

It's currently using docker buildx bake, which totally works. But porting to dagger could be a nice use-case