#Dagger Shell on GHA/Depot

1 messages · Page 1 of 1 (latest)

proper zenith
#

Hello,

I would like to get some more information about Dagger Shell in GitHub Actions.

When I run Dagger commands with the shell configured for Dagger, as explained in the documentation:

shell: dagger {0}
run: |
    # Return digest of the built container
    .  --debug-mode | apps | demo-app-typescript | build | as-tarball | digest

    # Run tests
    .  --debug-mode | apps | demo-app-typescript | test

I can't understand why I see error warning logs like this appearing in the UI:

  • 10:00:31 WRN failed to fetch branch err="error fetching branch from origin: exit status 128\nfatal: shallow file has changed since we read it\n"
  • 10:01:07 WRN failed to fetch branch err="error fetching branch from origin: exit status 128\nfatal: Unable to create '/home/runner/work/john/repo-example/.git/shallow.lock': File exists.\n\nAnother git process seems to be running in this repository, e.g.\nan editor opened by 'git commit'. Please make sure all processes\nare terminated then try again. If it still fails, a git process\nmay have crashed in this repository earlier:\nremove the file manually to continue.\n"
  • 10:00:30 WRN failed to fetch branch err="error getting reference "refs/dagger/pull/12/head": reference not found"

Regarding the setup:

  • I currently have several open PRs (Renovate updates)
  • I trigger the same workflow for each PR, but with different source code each time
  • I use the Dagger engine from Depot, which is therefore shared between the PRs
  • When I wrap several Dagger commands with the shell, I see ⬆️ error warning logs appear

I don't have this behavior if I don't use the Dagger Shell.

Thank you for your help!

maiden willow
#

could this be related to the core git refactor @vague cobalt ?

proper zenith
#

Everything runs on:

dagger v0.18.12 (docker-image://registry.dagger.io/engine:v0.18.12) darwin/arm64

vague cobalt
#

potentially? the directory /runner feels like it's the runner host though, not inside the engine which has slightly weirder paths

#

probably related to extracting the telemetry labels?

#

does the job actually fail @proper zenith? or do you just see the WRN (warnings)

proper zenith
#

Only warning.

#

The warning message changes, but I think I have listed all the possible occurrences above.

#

Dagger Shell on GHA/Depot

unique tree
#

if this doesn't happen outside the shell seems that it might be related to how the telemetry label recollection works. Let me try a quick repro. We should be able te repro locally as well

proper zenith
#

I quickly checked, I really have the impression that I get this warning every time I use the dagger shell.

#
name: Debug
on:
  pull_request:
    types:
      - opened
      - reopened
      - synchronize
      - ready_for_review
permissions:
  contents: read
env:
  DAGGER_PROGRESS: dots
  FORCE_COLOR: '3'
jobs:
  debug:
    name: Debug
    runs-on: depot-ubuntu-24.04-small,dagger=v0.18.12
    timeout-minutes: 10
    steps:
      - name: Checkout
        uses: actions/checkout@v4
       
      - name: Debug Dagger Shell
        shell: dagger {0}
        run: |
          .help
unique tree
unique tree
#

here's my test GHA workflow:

name: dagger
on:
  push:
    branches: [main]

permissions:
  id-token: write # This is required for requesting the JWT
  contents: read  # This is required for actions/checkout

jobs:
  hello:
    name: hello
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Call Dagger Function
        uses: dagger/dagger-for-github@8.0.0
        with:
          version: "latest"
      - name: Shell
        run: .help
        shell: dagger {0}
        env:
          DAGGER_CLOUD_TOKEN: <REDACTED>

and the repo I'm using to test https://github.com/marcosnils/daggertest

proper zenith
#

Just in case, you have pushed your DAGGER_CLOUD_TOKEN on Git.

unique tree
proper zenith
#

Hello, I'm reaching out to follow up on this topic and ping you directly @ember narwhal.

The error is not as harmless as it seems. I'm trying to implement the following pattern (https://docs.dagger.io/cookbook#continue-using-a-container-after-command-execution-fails), available in the Dagger CookBook, which involves having a function that returns an object with a dir and exit code, because I want to export the dir regardless of the command result, and exit my Dagger shell with the return code available in the object.

However, instead of exiting with my return code, I have the impression that the dagger shell returns an error code due to this issue. My exec stop at $result | report | export . and never reach the last line.

Local test:

dagger <<'EOF'
result=$(ci | pr)
exitCode=$($result | exit-code)
$result | report | export .
.exit $exitCode
EOF

Un GHA/Depot:

      - name: CI
        shell: dagger {0}
        run: |
          result=$(ci | pr)
          exitCode=$($result | exit-code)
          $result | report | export .
          .exit $exitCode
unique tree
ember narwhal
#

Hey! 👋 So on our side, we are "just" starting the Dagger engine as a container, with a persistent disk mounted at /var/lib/engine, beyond that we are not doing anything special to the engine itself.

I defer to @vague cobalt / @unique tree for what's actually happening on the Dagger side... /home/runner/work is a local path in the Actions runner itself, so presumably this warning is coming from the dagger CLI in the Actions runner itself, and may not be related to the remote engine at all?

unique tree
#

that could happen if another instance of the dagger CLI is running or some other git command is running within the runner at the same time that dagger runs

#

the OP already discarded the possibility of something within their GHA workflow as the repro they provided is quite minimal

#

so my assumption is that the depot runner must be holding a lock in the git repo at some point on its provisioning process

#

@proper zenith would it be possible to run lsof against the shallow.lock file show in your output to see which process is currently holding the lock against that file?

#

so instead of running dagger, run lsof $path/to/shallow.lock and see what that returns

proper zenith
#

I'll give it a try. Cooking ⌛

proper zenith
#

I just added a step before the Dagger shell.

      - name: Debug
        run: lsof /home/runner/work/moonrepo-example/moonrepo-example/.git/shallow.lock
Run lsof /home/runner/work/moonrepo-example/moonrepo-example/.git/shallow.lock
  lsof /home/runner/work/moonrepo-example/moonrepo-example/.git/shallow.lock
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
lsof: status error on /home/runner/work/moonrepo-example/moonrepo-example/.git/shallow.lock: No such file or directory
Error: Process completed with exit code 1.

I'm experiencing some latency on GitHub when trying to get my runner logs, I'm trying to check what's inside these folders but I must wait for the logs to be available.

#

Everything looks good in /home/runner/work/moonrepo-example/moonrepo-example/.git/; I can see my code, the .git folder, and no shallow.lock before executing the Dagger shell step.

ember narwhal
proper zenith
#

Ok, I may have misinterpreted the problem and overestimated my understanding of the dagger shell.

result=$(ci | pr)
exitCode=$($result | exit-code)
$result | report | export .
.exit $exitCode

With this, my exit code var becomes a directory after the call to $result | report | export .

● result=$(ci | pr) 0.0s

● exitCode=$($result | exit-code) 0.0s

▶ .echo $exitCode 0.1s
0

▶ $result | report | export . 0.2s
/Users/john/Documents/GitHub/moonrepo-example

▶ .echo $exitCode 0.1s
Directory@xxh3:5936dab0092461fd

And if I use this :

result=$(ci | pr)
$result | report | export .
.exit $($result | exit-code)

I have the correct behavior, even though I still have the warnings, my shell script works as expected.

Can I have some explanations about what changes between the two? How do I end up with my directory in my exitCode variable?

Thanks!

unique tree
#

@proper zenith are you running that locally in your machine?

proper zenith
#

Yes. Trying in interactive mode and with :

# Fail
dagger <<'EOF'
result=$(ci | pr)
exitCode=$($result | exit-code)
$result | report | export .
.exit $exitCode
EOF

# Success
dagger <<'EOF'
result=$(ci | pr)
$result | report | export .
.exit $($result | exit-code)
EOF
unique tree
#

this is my repro:

type Test struct{}

type Result struct {
    Report   *dagger.Directory
    ExitCode int
}

// Returns a container that echoes whatever string argument is provided
func (m *Test) Test(ctx context.Context) *Result {
    return &Result{
        Report:   dag.Directory().WithNewFile("test.txt", "This is a test file"),
        ExitCode: 100,
    }
}

and this is what I'm running

dagger <<'EOF'
result=$(test)
exitCode=$($result | exit-code)
$result | report | export .
.exit $exitCode
EOF

I'm correctly getting 100 as the exit code when running that locally

proper zenith
#

Thank you very much, I will try this and see what the difference is with my code if I can't repro. Normally, the two should be equivalent, right?

unique tree
#

I'm using v0.18.12 FWIW

proper zenith
#

Same.

proper zenith
#

Ok, I have a repro, is it normal that the method in fail.test fails while test succeeds?

package main

import (
    "context"
    "dagger/dagger-debug/internal/dagger"
)

type Result struct {
    Report   *dagger.Directory
    ExitCode int
}

type DaggerDebug struct{}

// Works as expected
func (m *DaggerDebug) Test(ctx context.Context) *Result {
    return &Result{
        Report:   dag.Directory().WithNewFile("test.txt", "This is a test file"),
        ExitCode: 100,
    }
}

func (m *DaggerDebug) Fail(ctx context.Context) *Test {
    return &Test{}
}

type Test struct{}

// Fails
func (m *Test) Test(ctx context.Context) *Result {
    return &Result{
        Report:   dag.Directory().WithNewFile("test.txt", "This is a test file"),
        ExitCode: 100,
    }
}

Clean Dagger module with just the code above, hence the use of -m .dagger-debug

# OK
dagger -m .dagger-debug <<'EOF'
result=$(test)
exitCode=$($result | exit-code)
$result | report | export .
.exit $exitCode
EOF

# Fail
dagger -m .dagger-debug <<'EOF'
result=$(fail | test)
exitCode=$($result | exit-code)
$result | report | export .
.exit $exitCode
EOF
unique tree
proper zenith
#

I took some time to revisit the original problem, and I identified the difference between your reproduction and mine. You are dealing with a push on main event, whereas I am working in a pull request. Here is a repo with the reproduction (same as your code), but with both GHA flows, on a PR (with the warnings), and one on push (without the warnings). Depot is not involved here. Vanilla GitHub Actions. 😄