general

[hidden dirge]

Do arguments passed at the command line override those values in the .env file?

[winter linden]

yes.

[hidden dirge]

great, thanks - have open an issue 🙂

[digital tundra]

Just flagging here that the upgrade from v.0.19.3 to v0.19.6 caused our CI to clog. We noticed that the dagger call would only succeed if there was no other dagger call being processed by the engine. Also, the calls that failed because of that would be doomed to fail forever with session / cache key error messages, regardless of the dagger engine being processing other calls or idling.

Does Dagger cloud offer support plans in the enterprise tier?

[loud briar]

Can you share an example error? I've been reporting something that sounds very similar in https://discord.com/channels/707636530424053791/1426220130102411384 - if I run two or more jobs at once I get errors, but each job runs fine and succeeds as long as it's the only job running at any one time

[pseudo stream]

A link to a cloud trace with the errors would help a lot

[winter linden]

Yes we do have an enterprise offering. Although it depends what your definition of "enterprise" is 🙂 I will DM you to ask for more details.

[quick monolith]

Are you guys at KubeCon 2025 in Atlanta, I see you listed as a sponsor but I haven't been able to find you and you not appear on the vendors board?

[winter linden]

@warm temple is here 🙂 he's giving a talk tomorrow. We are sponsors but decided to not invest in a booth, we're a worldwide distributed team and it's a big distraction. We'd rather focus on shipping & supporting the community.

Kyle lives pretty close so it made sense for him to go. He's representing us 🙂

There are also several Daggernauts including @fossil pine and @empty jay

[warm temple]

Yeah anyone who wants some socks at Kubecon, let me know 🙂

[quick monolith]

Im here from Colorado , Id stop in to hear what Kyle has to say and meet. I got Dagger on an approved eval list for a proj within the MDA (Missle Defense Agency) but we are actually on a Stop Work order until they straighten out the budget mess and I need to make some traction with it for a POC/MVP demo.. hence why I'm investing my time here at KubeCon. If ya have any details on where/what he is speaking at i might be able to cross his path?

[warm temple]

My talk is 3pm tomorrow! https://sched.co/27Faa But I'll be around the expo hall all week as well

[quick monolith]

got it 👍 I
I''ll be there

[rich rivet]

Error

[unborn pendant]

was it recorded?

[warm temple]

Yes! I'll share the YouTube link here once it's up

[cursive bridge]

Is there a way to access constants defined on one module from another? Say a test module accessing constants defined in the main module? I tried doing a normal go import, but then a dagger update seemed to get into an endless codegen process (4+m before I canceled).

[cerulean token]

👋 I've got a fmt function in my module that returns a changeset after running various formatters. In CI, I want to run something like: fmt | isEmpty ? nil : error in Dagger shell where the error case causes dagger to exit 1. Is that possible?

[winter linden]

Here's how we do it in our CI: ~~https://github.com/dagger/dagger/blob/main/.dagger/generate.go~~

--> slightly cleaner version https://github.com/shykes/dagger/blob/ci-faster-load/.dagger/main.go#L27-L104

Our implementation is slightly more complicated, to get a more granular error - not just "the diff is not empty" but "the diff from this specific component is not empty".

Otherwise we could just do:

func (m *MyMod) Generate() *dagger.Changeset { ... }

func (m *MyMod) CheckGenerated(ctx context.Context) error {
  noChanges, _ := m.Generate().IsEmpty(ctx)
  if !noChanges {
    return fmt.Errorf("generated files are not-up-to-date")
  }
  return nil
}

[cerulean token]

is it possible to define that function in the shell? or would I have to define it in my module?

e.g.

errIfNonEmpty() {
  if ![[$1 | isEmpty]]; then
    exit 1
  fi
}

fmt | errIfNonEmpty

I only ask because checkFmt would not have any use outside of CI which irks me a bit (locally I'd just run fmt)

[winter linden]

It's probably possible to encoded it in the shell, but assuming you call it from CI, then it sounds like you should not do that, and instead make it a function

It's also useful outside of CI btw. It tells you if you forgot to generate something before you commit & push

[warm temple]

it could be a common enough thing that assertEmpty or mustEmpty would make sense in the api?

[cerulean token]

yeah I'm trying to keep the implementation details out of my dev module, instead only keep the commonalities between dev and CI there, but you're probably right and that is just a bad pattern to begin with. thanks!

[cerulean token]

despite my just saying that i may be using a bad pattern, I do like this 🙂

[winter linden]

Yes that could be nice. Doesn't change the best practice IMO. It should still be a check function, this will make it a little simpler to write it 🙂

Related: I was just thinking that once dagger checks is solid, we should move on to dagger generate... 😇 And maybe that could just get a dagger generate --assert-empty ?

Imagine: dagger generate sdk/* engine docs

[ancient ivy]

Hello, I have a problem, I am using dagger with go, in terminal go mod tidy works to my private repos in gitlab, but inside dagger I get permission error

Please help

[mild coral]

Blueprints 🟦 + Toolchains 🛠️

[mild coral]

Function Caching + Interfaces Possible Bug

[torn wren]

Does the "with-self-calls" features work with the Python SDK?

[jagged flicker]

not yet 🙁 it should soon, I have to finish some changes in the python sdk that I put on the side for now. I'll see if I can possibly have them this week

[shell hearth]

Hi all,I'm pretty new to Dagger & using it across 2 organisations, but I'm seeing this error when I run out functions, despite having logged in successfully using dagger login <org>…

WRN consume error path=/v1/metrics traceID=******************* clientID=****************** err="re-export metrics: failed to export resource metrics: failed to upload metrics: failed to send metrics to https://api.dagger.cloud/v1/metrics: 401 Unauthorized (body: {\"message\":\"invalid API key\"})"

Any ideas on why this might be, or how I fix this?

[shell hearth]

Hi all,I'm pretty new to Dagger & using

[cursive bridge]

Is there a way to access constants

[stoic knot]

Has anyone used Dagger Directory as a virtual FS in VS Code?

[cursive bridge]

Looking at the function caching docs, I'm wondering how dagger avoids cache hits across 2 pipeline invocations.

My thought is say I have a module that does a build of a project. The build function can take a directory to build, but defaults to .. If this function is run as dagger call module build in dirA and in dirB, how does dagger ensure that a cached entry from running in dirA doesn't affect running in dirB? The docs mention that the function cache keys use the dagger module code and inputs/outputs, but those would all be the same in this scenario wouldn't they?

[winter linden]

If dirA and dirB are different, then the actual inputs will be different, and there will be no cache hit. Dagger's cache system is quite sophisticated and knows what to ignore and what to include in the cache keys.

For example it knows that +defautPath="." when evaluated in dirA, is not the same as when evaluated in dirB

[cursive bridge]

I figured that was the case, but I couldn't verify. The docs weren't specific enough so I couldn't be ready to answer that question from others.

[winter linden]

Docs are a work in progress 🙂 Thanks for the feedback

[raven stag]

Random question.
Is there any functionality I could use to identify "how much" of the cache usage belongs to a specific dagger call?
We're seeing some massive increases in our cache volume and due to the amount of concurrent dagger runs (shared engine) we're having some issues identifying which one is causing this huge increase of disk usage of the cache.
I wonder if there's a way that we could code something to query the usage of cache before/after (in the same code the pipeline is running would be fine)

[fresh pike]

Could you please add back the link to the changelog, it has been removed from the top level documentation. With these frequent updates where the CLI is nagging right away when there is a new version that link is a convenience feature.

[winter linden]

Hi all,

Dagger 0.19.7 is out!

• Many bug fixes
• Speed improvements
• A new experimental command we're excited about: dagger checks 😁

[blissful stratus]

dagger checks looks like something I have unknowingly been waiting for 🥳 ! Is it already usable from the typescript module sdk?

[elfin frigate]

yep! just need to annotate functions with the new @check decorator

[winter linden]

Checks are very exciting 😁 We're adopting them for our own e2e tests and it's very fun to develop and use.

[mighty flax]

Hey. Thanks for the ChangeSet object it really is useful ! Wanting to use in CI. Is there a flag that we could use to programatically apply ? I get a could not open a new TTY: open /dev/tty: no such device or address on Github Actions

Hey. Thanks for the ChangeSet object

[sick monolith]

https://tenor.com/view/bane-no-banned-and-you-are-explode-gif-16047504

[raven stag]

👋 Is the @check decorator supported in all SDK's? Where can I find some docs / PR ?
I can't seem to find anything in the release notes PRs included in 0.19.7 😅

[jagged flicker]

This is the PR that adds the check pragma to Go, Typescript and Python. For the others I don't think it's supported yet. It's a matter of calling .withCheck() on the function typedef to mark it as a check. For SDKs it's only a decorator, there's no extra logic other than that.
There's also this PR that uses : as the separator inside check hierarchy

[raven stag]

Switch checks to @check pragma, improv...

[chrome moss]

Hey all, quick question. We have some modules that accept a dagger.GitRef only for purposes of releasing/versioning. We want to be explicit here to avoid checking in sensitive files and ensure clean repos. However, this has an issue of not being able to use git submodules due to dagger attempting to check out/update them and failing auth. Do you have any recommendations for this or is it something not really supported? I only saw dag.Git() have options for tokens, and I dont see a way to convert a GitRef to that, especially since any attempt to use the gitref causes the error.

[sharp marsh]

submodules auth both via http and ssh should be supported per https://github.com/dagger/dagger/pull/10855#discussion_r2266427963. Have you checked this already?

[chrome moss]

Yes, that is what I was referring to in regards to dag.Git(). I am referring to using a dagger.GitRef instead. in ex:

func Ref(gitRef *dagger.GitRef) {
# do something with gitRef
gitDir := gitRef.Tree()

dag.Container().WithMountedDirectory("repo", gitDir)
}

Doing it this way allows us to be more flexible since we can accept a local git repo vs using dag.Git() that only takes a url

[warm temple]

as promised! https://www.youtube.com/watch?v=tvgMu1yTo20

[sick monolith]

does anyone know/have a dagger module that defines 'interfaces' . i know right know its go/typescript/python

just wondering if theres any modules out there to look at which is defining them

https://docs.dagger.io/extending/interfaces/?sdk=typescript#declaration

A real world demonstration for this would help me a bit

[elfin frigate]

Here's one: https://daggerverse.dev/mod/github.com/dagger/dagger/modules/evaluator@881bd24b092f1c96a3baa3cf1c0a618aa29f2ced (topic of https://dagger.io/blog/evals-as-code)

[sick monolith]

Thank youuu

[loud briar]

Minor annoyance in terminal output. I think Expand: true causes any item in the WithExec array that has a ${...} to be single-quoted in terminal output (but not during execution, which works). Copy pasting the terminal output doesn't work because of those single quotes.

Example: terraform init -backend=true -backend-config 'bucket=${TF_VAR_account_id}-tf-state' is displayed in my job logs. The command actually works when run but I can't copy paste it without editing first because of those single quotes

[sick monolith]

hey, if someone asked about datetime support in dagger, like other types float, int and so on... would that be beneficial to anything when working cross-module/interfaces and such or was datetime discussed already in the past?

I like the idea of being able to return a datetime, time or date field, even though 'strings' do work

does it open a can of worms when it comes to cultureinfo/serialisation

[slender charm]

I think I am late to the party but seeing the full commands auto expanded in the TUI is such a huge improvement, especially for debugging any interpolated values.

[elfin frigate]

glad you like it! i was worried not doing it everywhere might be confusing, but the readability boost seemed worth going for

it won't interpolate with expand: true if that's what you mean though. since that happens at runtime. interested in solving that if that's what you were hoping for

[slender charm]

Haha, I meant this:

      .withExec(["apt-get", "install", "-y", `ros-${this.rosDistro}-desktop-full`])

turns into this:

withExec apt-get i
nstall -y ros-noetic-desktop-full

That is properly interpolated and shown in the TUI and I love it! In the past I have wasted way too much time debugging simple things that were just not being interpolated properly for whatever reason.

[digital tundra]

Is there any recommendation against using a remote docker server and in favor of using a remote dagger engine?

[sharp marsh]

Not that we're aware of. There are some users that use this approach mostly because of the ssh transport docker provided which is quite convenient. IIRC @winter linden also does this to connect to his home server

[digital tundra]

We keep falling back to our legacy CI solution because this issue won't stop happening. We've tried upgrading 2 times but it keeps on going. I thought that maybe the fact that we use a remote docker server instead of a remote dagger engine could be a contributing factor. Even though it also happens locally. Do you guys reckon Claude might have a chance on fixing this? We're willing to spend the necessary tokens 😄 https://github.com/dagger/dagger/issues/11293

[sharp marsh]

@digital tundra is this something you can systematically reproduce? If we do have a way to get a consistent repro, we can take it from there

[digital tundra]

I think the issue was already acknowledged, if you check the linked PRs and relared conversations it seems like it's a known issue. But I'll collect some traces make them public and share privately with you guys.

[ancient ivy]

How I could use log, or print in go module inline, because log and fmt not work

[quick monolith]

Is there a resource that covers setup of dagger within an airgap environment with a private repo/registry?

[loud briar]

Doubt it, but there's not a lot to it. Host a Dagger engine within your walled garden, then whatever is running your jobs needs to be told about it with the _EXPERIMENTAL_DAGGER_RUNNER_HOST: https://docs.dagger.io/reference/configuration/custom-runner/#connection-interface. As long as you have a route to the engine from whatever runs your jobs you're golden

Some more useful info about setting up the engine here: https://docs.dagger.io/reference/configuration/engine

[dense prawn]

Hey everyone! 👋

I just released Shai-Hulud Scan, an open-source tool to help visualize and analyze the recent "Shai-Hulud 2.0" npm supply chain attack (discovered by Wiz).

What it does:

• 🕵️‍♂️ Checks your project: Drop a package-lock.json or t sbom o see if you're using any of the 795+ compromised packages.
• 🔒 Privacy First: The web version runs entirely in your browser (no data uploaded).
• 🛠️ Tech Stack: Built with Next.js, Tailwind (CRT theme), and #Dagger.

It's designed for education and awareness. Let me know if you have any feedback or questions!

You can also use dagger function call to run it in your CI

Thank to #Dagger for making this safe 🙂

Link: https://mchorfa.github.io/shai-hulud-scan
Repo: https://github.com/MChorfa/shai-hulud-scan

[sharp marsh]

We acknowledged that it's something that can possibly happen. It's hard to pin point the issue without a trace or a way to consistently repro 🙏

[sharp marsh]

You can use fmt or log. You're probably not seeing it because the default verbosity doesn't show that. If you increase the verbosity of the TUI you should see it

[sharp marsh]

Nothing official. There are some Discord users which started some conversations and opened issues about it but it's not currently something we officially support.

If you want to make the investment in seeing how this could work we can definitely help by providing pointers and discussing what would be the best way to implement this. Having said that, I just want to be open that this is not currently in the top most priorities

[sick monolith]

I really wonder about package managers with post/pre install script execution

One interesthing topic that's been discussed i think ive seen in a few places now is forks of highly popular used frameworks and having small pieces with compromised packages with similiar names and LLMS being left to install packages and then end up with malware

[sharp marsh]

yep, it not only applies to packages but also binaries that people download from multiple sources which have access to all the files the user has access to. I think that this is also another benefit of Dagger. By running everything sandboxed, you reduce the attack surface considerably and also allow oraganizations to add more safeguards to prevent these type of attacks

[sick monolith]

is the 'W' overridable on the TUI? when running WSL, i get an error as it cant open up a browser, but thats because WSL is a linux shell with no gui. since WSL has the ability to call into native Windows exe, i could get it to open in windows OS browser

[sharp marsh]

it's using xdg-open under the hood so it'll try to use whatever program you have configured as a default-web-browser via the xdg-settings

[sick monolith]

thank you, not used to linuxy things but im trying to now use a mix of dagger.exe (win) and also WSL for development / linux tools

the weird thing is i can call dagger.exe from WSL as well 😂 and you can even pipe stuff into a windows exe like echo"something" | clip.exe - very cool/weird

[sharp marsh]

lol.. that seems weird indeed 🤪

do you have the xdg-open binary in WSL?

[sick monolith]

yeah, that does work

I fixed it

xdg-open

# Forward URLs and files to Windows
explorer.exe "$@"```

hmm, hopefully that doesnt break other stuff...

[sharp marsh]

I don't see why it would. Maybe it fixes some other stuff?

[sick monolith]

[spring orbit]

I can't get this example to work: first of all I can't get the build --source=$completed | as-service | up --ports 8080:80 to stop, and anyway any time I re-run it and it regenerates a solution the served application always has a black background. What's going on?

ctrl-c or q don't do anything the service keeps running

the only way is to enter the interactive prompt and Ctrl-d to quit the whole thing but then I'm also losing everything

Nope I don't get it. And half the time it fails, this is how it failed most recently (attached). ERROR: function "build-env": cannot expand function argument "source": binding "completed" undefined [traceparent:ff7bb0099006b0d324ad7f8e44f082af-6b3d7eca39885

[vestal creek]

Not sure if anyone else misses the Cue SDK, but I’ve added Dagger as a backend to Cuenv

https://cuenv.dev/dagger-backend/

[winter linden]

Nice 🙂

[vestal creek]

Still a WIP but it’s working well for me atm

[sick monolith]

@winter linden , i asked chatGPT to make a joke for daggernauts, how well did it hit? 😂

ChatGPT said:

Why don’t Dagger developers ever get lost?

Because no matter where they go, they always follow the graph — and if something breaks, they just say:

“Relax… it’s cached.”

ahh it's creepy good with no context on some topics now

[obtuse iris]

My goodness... I just jumped from 0.18.19 to 0.19.7. Is it just me or is the CLI like 3-4X faster in startup and execution now?! Huge quality of life improvement! I find the new tty TUI much easier to read and interpret, also. Fantastic work to all who made that happen ❤️

[winter linden]

Ha ha glad you noticed 🙂 Yes we've been focusing on UI polish and performance in a major way. More improvements coming!

Also coming: dagger-native cache-aware clustering, test splitting, native check API, and more

We also shipped an experimental DSL for performance-optimized modules (optional, you can keep writing go, typescript, python, php, java, elixir etc)

[cursive bridge]

Is it possible to embed go structs that use dagger types/module definitions in other dagger modules?

[sharp marsh]

yes as long as those structs are not part of the module function arguments or return types.

[cursive bridge]

Hrm. When I try the code generation seems to go into la-la land and never complete (at least not after 1+m). I'm trying something like:

`pkg/util/store.go
type struct A {
ctr *dagger.Container
}

func (a *A) StoreContainer(c *dagger.Container) *A {
a.ctr = c
return a
}

moduleA/main.go
import "pkg/util"

type struct B {
util.A
dir *dagger.Directory
}
...
`

Is the problem there that the function is returning *A?

[sharp marsh]

that's because struct B is the module struct and dagger will try to expose the embed as a public field in the API. If you add // +private above util.A that should allow you to use it

[cursive bridge]

Would adding // +private above the embed still allow ctr and StoreContainer to promote to the module struct as happens normally with Go?

[sharp marsh]

no, we don't currently support that due to the fact tha otherwise, dependency management becomes more complicated. You'd have to manually create a StoreContainer method in your B module and call the inner util.A method currently.

[winter linden]

I do wish the Go SDK supported embedded types... I get it @cursive bridge . sorry

[cursive bridge]

That's workable I think. The intention is to provide common function/impl for work that has to be done across modules. Not the end of the world to have a function in each module that calls the common impl.

[cursive bridge]

No worries. Just trying to figure out what I can do. I hate code duplication. 😄

[winter linden]

same 😁 another option is importing a common dagger module

[cursive bridge]

I couldn't see how importing a module would solve my issue, however since I'd have to create the top level functions in the modules themselves it might work too. I'll play with it.

[cursive bridge]

Can I use WithRegistryAuth to provide pull credentials for a Container.()From() call? If so, do I need to call WithRegistryAuth before From()?

[cerulean token]

this is exactly correct

[cursive bridge]

Which statement? 😄 That WithRegistryAuth() needs to be called before From()?

[cerulean token]

both statements. yes, withRegistryAuth() must precede from()

in fact, I think that it must immediately precede it

[cursive bridge]

Well I can verify it can't FOLLOW it. 😄

[loud briar]

You can use WithRegistryAuth any time before the Container.From is evaluated and it works for the remainder of that session

It doesn't have to be in that Container.From either.

[stoic knot]

Say I give an agent / llm an exec tool that effectively runs dagger.Container()...Exec(), and I give that container secrets the Dagger way

1. Will Dagger obfuscate them from the LLM if the tool outputs them?
2. What if the llm runs cat secret.txt?

I'm basically passing exit code, stdout, stderr back in the tool response

[winter linden]

good question. I'll let @elfin frigate or @warm temple answer.

ALSO, note that Dagger already provides the plumbing for mapping functions to LLM tools. Before you embark on a journey to reimplement that

[stoic knot]

I'm using ADK-go, which has similar "I write function, framework manages schemas and such when making api calls to llms"

[winter linden]

1. You can expose any dagger module over MCP with dagger mcp
2. For more fine-grained control, you can use the Dagger API to create an environment, map functions and objects to it, then attach a LLM to it

[stoic knot]

For 2, did you see my post here: #agents message

[winter linden]

Looks like you're on the "reinvent" path, nothing wrong with that 👍 as long as you're aware you don't have to

[stoic knot]

I connected Dagger to VS Code virtual filesystems / terminals, and then give those to the agent

well, ADK does a ton of heavy lifting on the agentic side

learning about ADK abstractions was like learning about k8s abstractions, they are good

[winter linden]

I guess it boils down to whether all your tools will map to dagger calls. If so, you don't need the ADK layer. If you're gluing dagger and non-dagger functions, then it makes sense to add a layer

[stoic knot]

ADK is up a level, manages event loops between clients, sessions, and underlying agents defined however you want

like how k8s takes care of all the bookkeeping and scheduling stuff

it also gets very much into calling the apis / functions, propagating events and states

[winter linden]

Yeah Dagger API does all that

(but with the limitation that all tools must map to dagger functions)

You can build a claude code clone on top of pure Dagger API for example

[stoic knot]

does Dagger handle things like user level settings or memories across sessions?

one place Dagger shines is that one can "fork" a session and travel down two conversation histories from a shared starting point

[winter linden]

Those are all tools under the hood. We stick to tool-function mapping + persistent objects with Dagger object types. No first-class concept of memory, but you can build it on top of those concepts

User-level settings: depends what you mean

[stoic knot]

In ADK, I store something like user:key=value into the state, and that state is available in every LLM and tool call

[winter linden]

cc @elfin frigate I don't know how you would build that abstraction on top of dagger API

It looks like dagger MCP is probably the right integration point for you @stoic knot

[stoic knot]

that's why I think ADK sits a layer up from where Dagger fits into my puzzle

[elfin frigate]

i've just been doing that with string env bindings (e.g. here and here)

they get put into a tool description, so they're sent in every request

[stoic knot]

state in ADK is transparent to the tools and agents, they don't see it unless you explicitly use it in their implementations

Here's an interesting sequence of events to think through

1. user invokes agent against dagger dir/cntr
2. diff is presented in vscode
3. user makes changes
4. ...
5. user calls agent again, expecting their changes to be visible for ai to work on with the next message

The whole forking virtual FS/terminal based on dagger is really freaking cool tho. I'm going to polish it up and use it for a lot more things

One thing tho, Dagger IDs get REALLY LONG (encoded graphql like stuff) (feel like I have deja vue writing this now...)

In this sequence, is it possible to get a sha like string like I do if I simply call publish on the same container?

I'd like something like that without having to actually push the container

[winter linden]

My gut feeling that you're reinventing the wheel is intensifying fyi @stoic knot

but I might be wrong

[stoic knot]

the main user-event loop seems way harder to implement directly in Dagger

[winter linden]

🧵 adk-go + dagger

[sick monolith]

bah, i think i found a directory creating bug with dagger init

[cerulean token]

dagger checks is awesome for a pre-commit hook and for CI. thanks!

[winter linden]

working on making it even more awesome 🙂 btw in the next version we're renaming it to dagger check (singular) to align with other commands we're working on : dagger generate, dagger up...

(left an alias to checks plural to avoid breaking early adopters like you)

[cerulean token]

generate + check

[twilit minnow]

Hey all! i'm an Earthly refugee and could someone please think through what approach i could take to port my WITH DOCKER + compose "problem" over to dagger with me for a moment? 😄 tl;dr using it for launching a k3s cluster in to an overlay network, details below

[twilit minnow]

I have a k3s cluster defined and its nodes ctr load-ed with container bundles and helm charts from the Earthfile's build targets, as well as miscellaneous kubernetes resources created ( nginx deployment for the chart repo, etc ) in a compose stack enabled mostly by a dependency graph of completable and readiness-checked services.. it's a large yaml expressing a complex order of execution in a flat and tedious to manage document. and i would really prefer a set of dagger.Services bound together and different steps of the initialization exposed as different dagger functions instead ( this may be feasible from my research so far and there are existing modules that are a near match ) The ultimate goal of this entire setup however is for most of these services, specifically the actual k3s nodes, to run on, at minimum an isolated docker network for strong and easy to comprehend isolation guarantees. I see a few options so far, none too appealing:

• I could just run the earthly dind image in my function, fork off a dockerd the same as WITH DOCKER does ( this guarantees the clean docker state ), create the docker network the same way ( network create --attachable --internal ) and stick to the compose monster

disregarding the clean docker/image cache state requirement and focusing on network isolation:

• i could start node containers with network management privileges and isolate them with ipfw in a shell script
• i could start thinking if configuring network isolation ( routes only to bound services ) is in scope for buildkit and dagger.Container APIs 😄

i'm ( so far ) a very casual reader of the buildkitd source and apis and only starting out with dagger, but it seems to me that one would need to carry this configuration, likely a boolean to the cni configuration as it becomes part of the runtime spec ( as a namespace ) and a way to resolve service names to produce routes

[winter linden]

Hello and welcome!

Not sure if it fits your use case, but the Dagger API supports running privileged containers, for example you can run dockerd, and by extension k3s, encapsulated as ephemeral dagger.Services, and from there make kubectl calls against it.

We actually do this for our own test environment, to test Dagger's official helm chart. You can see the code for that module here: https://github.com/dagger/dagger/blob/main/toolchains/helm-dev/main.go

Note the use of a reusable k3s module. It's developed by @sharp marsh and we vendor it into the dagger repo to squeeze out runtime performance.

[twilit minnow]

Thanks! Yes i think i will go for the privileged Container and execute ipfw prior to launching the k3s binary, it seems the easiest. Do you think though that api to allow configuring a cni implementation to do overlay would be something in scope for dagger.Container/buildkit

[sharp marsh]

We don't have fine-grained networking management at the API level as you probably know. In Dagger all spawned containers share the same bridge network and can talk to each other via IP or DNS resolution.

If your requirement is to simulate that each k3s node lives within it's network, I think my approach would be to start a docker daemon within Dagger and then build your own "overlay k3s" module which puts each node in a container with their own overlay network. This seems to be the most realistic scenario while still allowing you to resume some of the architectural setup that you have today.

[twilit minnow]

We don't have fine-grained networking

[marsh timber]

Can anyone confirm for me please that directory exporting requires docker? (running in a kube cluster which doesn't have docker)

[winter linden]

docker is not a requirement for any feature of dagger. You need a way to bootstrap the dagger engine by running it inside a (privileged) oci container. That could be with docker, podman, kubernetes or any other oci-compatible runtime.

[marsh timber]

Yeah that’s fine, just getting an error stating I need a particular version of docker is all 🙂

[winter linden]

ah - could you share the exact error message?

[marsh timber]

When trying to export a directory to be clear. So thought I’d ask

[marsh timber]

Yeah let me jump onto work comp. Uno memento

14:44:45  Error: Post "http://dagger/query": command [kubectl --context= --namespace=dagger exec --container= -i dagger-dagger-helm-engine-j2775 -- buildctl dial-stdio] has exited with exit status 1, make sure the URL is valid, and Docker 18.09 or later is installed on the remote host: stderr=E1204 04:44:44.737028    7358 v2.go:167] "Unhandled Error" err="next reader: websocket: close 1006 (abnormal closure): unexpected EOF"

14:44:45  E1204 04:44:44.737076    7358 v2.go:129] "Unhandled Error" err="next reader: websocket: close 1006 (abnormal closure): unexpected EOF"

14:44:45  E1204 04:44:44.737090    7358 v2.go:150] "Unhandled Error" err="next reader: websocket: close 1006 (abnormal closure): unexpected EOF"

14:44:45  error: error reading from error stream: next reader: websocket: close 1006 (abnormal closure): unexpected EOF

[winter linden]

This could be an engine crash... Can you check for logs with docker logs <CONTAINER> ? (or the kubectl equivalent)

[marsh timber]

Will do

[marsh timber]

i was too slow

but also any build adter this fails to complete

[halcyon sphinx]

Hey guys, what's the current best practice to cache Dagger-based jobs in CI (e.g. Azure DevOps pipelines)? I remember that a couple months ago, the Dagger team said something along the lines of "We're working on a new caching solution". Has there been any update on this yet?

[tender timber]

Hey guys, is there a way to limit provisioned containers resources in any way ?

[sharp marsh]

the only configurable option via builkit is to set the parent cgroup for all containers. It's not currently possible to specify resource definitions for each container independently

[tender timber]

Is there any documentation or example for this ? Specifiaclly for k8s enviroments

[sharp marsh]

no docs unfortunately. Here's the PR in the buildkit repo https://github.com/moby/buildkit/pull/2692. The TL;DR is that you need to set the defaultCgroupParent property in the engine toml config. The value needs to be an valid existing cgroup name

[tender timber]

Resources limiting

[cursive bridge]

Any known reason why using a service with spec.internalTrafficPolicy set to "Local" wouldn't work with a dagger installation from the helm chart? Would this be something that could be supported in the helm chart (I may be able to work on that)?

[sharp marsh]

Any known reason why using a service

[formal folio]

Happy to say that I just did pushed my first daggerized pipeline at my new company - no surprise - the DevOps team loves it. Keep up the good work, and I'll always be Dagger's biggest supporter.

[winter linden]

Hurray! Thanks for your support, let us know if we can help with anything!

[cerulean token]

dagger organically came back up in discussions amongst my team today 👀

[winter linden]

https://tenor.com/view/morty-rick-and-organic-is-gif-20712056

[chrome moss]

Quick question on dagger.Checks Are we meant to be able to access checks from modules we have as dependencies? For example I have a monorepo of various dagger modules I maintain, Can I create a new module that depends on them(or rather the tests really) and then call dagger.Checks to call all the checks from my dependent modules?

[winter linden]

I guess that would work, but unless you're doing something extremely custom, you shouldn't need to do that. Instead you would install those dependencies as toolchains (dagger toolchain install) which is a special kind of dependency that exposes its functions (and checks) to the end user. That way the main module simply aggregates checks from all its toolchains.

[chrome moss]

Ahh I didn't realize toolchains did that. Perfect. Thank you! Dagger is awesome

[icy flint]

anybody aware of work being done on a nushell sdk? combining dagger and nushell sure seems like an powerduo to me

[winter linden]

Not to my knowledge, but maybe we can get a group of nushell-loving daggernauts to make one? 😁 we're happy to help

[halcyon sphinx]

Hey guys, any update on [this](#general message)? 🙂 Notably, the same question was raised on Github shortly after. Maybe you could respond there for better visibility?

[icy flint]

that would be awesome, nushell's data driven everything combined with dagger would look like a superpower to me, not much of a software engineer myself though, but would be happy to help out with any testing

[chrome moss]

Hey all, quick follow up on this, how I meant to call this in code? Assuming I have various toolchains with checks cli wise dagger checks does exactly what I need, but I'd like to wrap my checks into another function to perform other tasks along with it. The only way I could do it was something like dag.CurrentModule().Source().AsModule(dagger.DirectoryAsModuleOpts{SourceRootPath: "path/to/toolchain"}).Checks() but that only calls 1 toolchains checks. Trying without giving the source root path leads to no checks are found/seen

[warm temple]

This might be related to a bug noted here: #maintainers message . I don't know if there's a workaround for dag.CurrentModule() since the CurrentModule type is different from Module. It may require a fix for that bug first

[winter linden]

Correct. @chrome moss what is your exact use case for programmatic call?

If your module exposes checks, it's potentially weird that it "checks itself"

For the equivalent of dagger check -m FOO You can do: dag.ModuleSource(FOO).Checks().Run().List()

[chrome moss]

So the use case is I have a monorepo with 9-10 dagger modules. The idea was to create a new module as my ci pipeline that uses them all as toolchains. Then I can run tests and do release related tasks when I push a change. So my CI module would have a function prerelease that runs all dagger checks of my toolchains first, and assuming those all pass run releasing stuff. This monorepo has all the modules our team uses for their own ci pipelines

[chrome moss]

Got it! I tried using source directly first, but I was running into weird issue where it would say couldnt find my dagger.json even though its there

[winter linden]

but how will you call your CI module?

[chrome moss]

dagger call prerelease assuming im at the root of my monorepo. Just for extra clarity, it would look like this:

.
├── .dagger #my "ci" module
├── dagger.json
├── docker #example toolchain of my ci module. These are what I actually want to test/release/use elsewhere.
├── git-cliff
├── release

[winter linden]

check then release

[icy flint]

what would be the recommended approach for hosting shared pipelines/modules/functions across multiple repos, I'm considering creating a private daggerverse repo that will host all of the modules that would be required, but is there a formal structure such a daggerverse should follow?

[inland plover]

what would be the recommended approach

[timber sphinx]

I haven't kept up with all daggers agent improvements. Have some general questions in a thread for those who have done a lot with the agent SDK (I've used before but was 4 months ago)

[steel sail]

Are there any ways to provision users automatically to Dagger Cloud?

[sharp marsh]

Are there any ways to provision users

[winter linden]

Hi all. We have disabled Github Actions for our own pull request checks. Instead, we are running Dagger on dedicated compute, straight from git events. Instead other words, Dagger-native CI 😇 Once optimized we think this can be MUCH faster and efficient than traditional CI.

If you're interested in evaluating this stack for your own needs, let me know in DM!

https://x.com/solomonstre/status/2001359991975088445

Solomon Hykes (@solomonstre)

Wait, where did Github Actions go? 👀👀👀 https://t.co/GxNTkkVnp0

X · Dec 17, 2025, 6:33 PM

[tired moth]

Please help to achieve this.
Awaiting your reply. Thanks

https://x.com/i/status/2001373329811181846

Jared Palmer (@jaredpalmer)

We’re postponing the announced billing change for self-hosted GitHub Actions. The 39% price reduction for hosted runners will continue as planned (on January 1)

We missed the opportunity to gather feedback from the community ahead of this move. That's a huge L. We'll learn and

X · Dec 17, 2025, 7:26 PM

[cursive bridge]

Minor doc issue:
https://docs.dagger.io/reference/configuration/engine/#garbage-collection

In the engine.json example, there is a , at the end of the "gc" example section which is incorrect if there are no other config blocks. That comma should probably be removed

[sharp marsh]

https://github.com/dagger/dagger/pull/11584

[cursive bridge]

I've managed to get the dagger-engine pod evicted from a kube node because of disk pressure. While I'm looking into node type options, I was also looking at garbage collection config. According to the docs, maxUsedSpace is basically the uppper bound on allowed disk space. What happens if the engine ends up using space beyond that value? Does it trigger the gc immediately? Does it fail the pipeline and stop executing?

[tribal quail]

hi dagger team, just wanted to shout out to the massive efforts put in release after release. As a dagger user i can see the project maturing like crazy.
I just discovered toolchains and i'm absolutely mind blown with the possibility of chaining it to the module (it's in the name i know)
Keep up the awesome work 👏

[winter linden]

Thank you for the kind words! Yes the combination of toolchains, checks and (soon) auto-scaleout opens many possibilities 😁

also we want to keep making dagger faster...

[tribal quail]

i was looking for documentation around checks but couldnt find much. Any pointers ?

[winter linden]

not documented yet 😬 but should be stable enough now. Basically you can implement checks (tests, linting, etc) as dagger functions.

1. Annotate the desired functions with +check or @check (ts, python)

2. list checks with dagger check -l

3. run checks with dagger check

4. You can filter which checks to run. Real-world example: dagger -m github.com/dagger/dagger check go-sdk

5. (coming soon) Dagger Cloud reports each dagger check directly as a github check

6. (coming soon) check functions can be dynamic (your module can return an array of them) so for example you can expose each individual test as a check, for test filtering and splitting

Here's an example of check in one of our own toolchains: https://github.com/dagger/dagger/blob/main/toolchains/installers/main.go#L20

[winter linden]

Checks work well with toolchains, because when you install a toolchain in your project, you also get that toolchain's checks in the context of your project.

For example if you install a Go toolchain, you might automatically get checks called go:test and go:lint

[tribal quail]

that's beautiful ! love it

[chrome moss]

Do you guys have a recommendation for deleting modules out of daggerverse that no longer exist? When I went to make an account it looked like daggerverse wanted github access as me which I didn't want to do/think was necessary? I just want it out of daggerverse

[winter linden]

Do you mean creating a Dagger Cloud account? (dagger.cloud) That gives you the option to authenticate with Github (or Google), but it doesn't control publishing on Daggerverse. That is done independently, by indexing public repositories

I don't think there's a way to remove it from the index yourself, sorry - but we can remove it for you manually

[chrome moss]

Maybe? I just went to daggerverse.dev and tried to login there because I dont see a way to delete modules that were previously published automatically. We have modules that we had but removed but are still in the daggerverse

[winter linden]

And in any case, we never index private repositories on daggerverse, regardless of whether you login with your Github account

[chrome moss]

I appreciate it, I don't want to make you have to do that manually so maybe this is just more of a heads up so you guys are aware(if you werent already). As an example: https://daggerverse.dev/search?q=act3-ai anything that has /daggerverse doesn't exist in our repos anymore so we have duplicate modules showing up when you search for them

[stoic knot]

Dagger layer diffs, as viewed like SCM in VSCode

[winter linden]

are you introspecting the ChangeSet type? Very cool if so!

[stoic knot]

yup! and the prev/next are images published by dagger as <session-id>:<pos> in history, but it could in theory work for any container & layers, like the dive tool

[sharp marsh]

just removed them and updated the search index. thx 🙏

[stoic knot]

I couldn't have done any of this without Dagger, much love!
https://bsky.app/profile/verdverm.com/post/3maetqcc4722f

verdverm (@verdverm.com)

2 days with gemini-3-flash, def a great model

- implemented autocomplete for its input
- environment as vscode scm with diffs
- sorted agents.md files, even discovered and adjusted its own prompt without prompting
- enhanced the ui around tool calls

changes spanning languages and front/backends

Bluesky · Dec 19, 2025, 11:27 PM

[torn wren]

I'm evaluating whether Dagger fits my central deployment repository use case, which manages deployments for roughly 50 Helm charts (a mix of third‑party and internal charts). Individual teams' CI pipelines publish container images and Helm charts but do not perform deployments; that responsibility belongs to the central repo, which must deploy charts to multiple environments (UAT, staging, production) and manage per‑environment values and state.

Today I use the Helmfile CLI (I could have used Helm, Kustomize, or Terraform) — these tools focus on templating and state management.

I know Dagger can deploy helm charts, but I'm unsure what advantages it would provide in this use case over my existing Helmfile workflow. It feels like it may reproduce much of the same functionality.

I'd appreciate your thoughts on this subject, I am trying to figure out how I should think about this.

[sharp marsh]

Hey Tony, welcome! Dagger itself is not a CD tool, but a programmable, modular and portable workflow engine which helps by keeping things consistent between a local experience and the things you run on CI.

Going back to your question, have you identified any particular pains or opportunities in your current setup which you might think Dagger can help?

One example within your use case which I've found Dagger being quite convenient is the ability to run more dynamic and complex tests after the charts are deployed to verify everything works as expected. Instead of relying on helm's limited testing capabilities or bash scripts, you can build a more robust and extensible testing capabilities into your workflow

[torn wren]

My pain is mostly related to Helm Charts themselves. The charts quickly become a poor leaky abstraction written in hard to read templating files. I would love to not use charts but I don't have much choice with the 3rd party charts and getting all the internal dev team to use something else might be possible but I would need to identify a good replacement... At this point I am accepting the charts as a "fact of life" and focusing on the CD part of the workflow.

You have given me something to think about with the post deployment testing. Perhaps I could use dagger as a thin wrapper around my deployment CLIs to do the deployments then extend that with tests. But short of that what I hear you saying is this might not be the center of the target as far as use cases go for Dagger.

[sharp marsh]

I can empathize with this. I have personally always been a proponent of gatekeeping those abstractions as much as possible given that once you open the door, it's very hard to go back as users have a wrong feeling of having more flexibility when in reality the absorb unnecessary complexity which generally yields to more headaches for the platform/infra/devops/sre teams.

Going back to the workflow + abstractions topic, Dagger really well suited for those kind of scenarios. It reminds me to this recent video of Kelsey (https://youtu.be/HdUbTyvrfKo?si=csPutiMNxAgRr-Go) speaking about the importance of platforms/devops teams to come up with the right APIs and DX for teams to move fast and with confidence. Dagger allows you to build these abstractions while also providing a sandboxed and performant workflow engine to orchestrate and distribute them.

If you already have some rough ideas of things you'd like to hack on and try, feel free to share maybe in the #kubernetes channel what's in your head and there's surely some other folks there which might be interested 🙏

[torn wren]

thanks this is helpful

[patent slate]

I totally agree with the point on smart abstractions—Kelsey is spot on there.

However, I think it’s crucial to define which APIs Dagger should own in a platform. To me, Dagger is the ultimate "Swiss Army Knife" for pipeline building, but it shouldn't be the "end API" for the entire platform.

Its core strength is being a programmable DAG engine. By definition, a DAG is finite; it calculates, executes, and ends. This makes Dagger the perfect Job Runner, but ill-suited as a Service Manager.

A full platform needs APIs for long-running state, durability, and event listening—things Dagger lacks by design (unless you force it, which risks rebuilding a wobbly version of Kubernetes).

In my view, Dagger fits perfectly when scoped to the "ephemeral execution" role, but we still need other distinct layers (like K8s or Temporal) to handle the "long-running management" role. Dagger is the best tool for the job, provided we agree on what the "job" is.

[sharp marsh]

Yes, totally. There's never going to be a silver bullet when it comes to building platforms. The problem we have always focused on while building Dagger has been providing a better workflow engine to build, test and package applications or any other task which results in one or many artifacts.

Going back to the OP scenario, it fits quite nicely as an alternative to come up with new abstractions to simply how users interact and reason about an important part of their SDLC which involves handling brittle yaml configs

[patent slate]

Yeah, we're slowly evolving away from using GitOps at all (as in using git) for the production applications i.e. the apps that end up user facing or support user facing apps. We are devising a process where ArgoCD is given manifest data built from a database (following the Score spec). So, it is sort of moving git into a database, if you will (because having to use git to make infra changes "on the fly" is a real PITA). @torn wren - have a look at Score. It might give you some inspiration. 🙂

Btw, we are only using the Score spec to define workloads, not its tools. 🙂

[cerulean token]

we're doing "OCI ops" instead of GitOps with FluxCD. All of our Kubernetes manifests are stored in an artifact in an OCI registry, just like our images and Helm Charts. I like it a lot more than GitOps, as it turns out.

IMO GitOps' boon of using git to be familiar was also its bane--everyone has so many opinions on how to use git for regular SDLC and they try to force all of them onto GitOps, and suddenly you can't automate anything because your automated PRs to promote your already-tested artifacts to a new environment need tested again, manually reviewed, and approved.

[winter linden]

Gitops never made sense to me

[cunning jolt]

Are we heading towards Dagger modules as OCI artifacts?

[stoic knot]

I'm headed towards agent chat sessions as OCI artifacts via Dagger!

[stoic knot]

Does dagger have an AGENTS.md (for dev'n) or LLM.md (for users)? This second is something I'm seeing more of, a markdown file for users of a project they can include in their own project using your project

I would imagine several LLM.md, per SDK and one for the CLI? I'm about to make something for using the Go SDK

[tribal quail]

hey everyone. i'm failing to understand the point of blueprints. If i call dagger init --blueprint=XX this produces a dagger.json file but I cannot declare any other logic on top of it ( my own functions) .
How is that different from calling the same module directly dagger -m XX call ? \

[winter linden]

it's for central platform teams who want to minimize friction for their dev teams to adopt dagger.

[tribal quail]

wouldn't using dagger -m XX satisfy the same need though ?

[cunning jolt]

Blueprints vs Modules

[stoic knot]

With this one weird trick...

[stoic knot]

So services can be started on demand or manually, if I wanted something like on demand, but stay up for 30s and shutdown if nothing happens... is there anything in Daggerland that can help me there, or am I most likely shortest pathing to manual up/down and managing that window and deciding if anything happens

context: I want to run LSP in Dagger and only have it running as needed (if I have dozens of these across agent environments / vscode workspaces)

[sharp marsh]

when using services via WithServiceBindings they're automatically stopped once they container(s) that requires them doesn't use them anymore

[sick monolith]

https://tenor.com/view/beautiful-tree-gif-2023-christmas-tree-marry-christmas-gif-182709482597025330

Merry Christmas to all daggernaughts and the dagger team

Who knew!!?!!

[stoic knot]

I'm giving my agent more dagger toys for xmas 🎅

[jagged epoch]

Merry Christmas

I hope all on the Dagger team and extended team is having a great holiday season.

I wanted to share some of the cool things I did with AI. I created an MCP server for mouser electronics to help verify and price BOM for this tube amp build with AI design assistance. I reverse engineered Lutron's dimmer and Keypad protocol for an upcoming product. I know it's not Dagger specifically, but I wanted to follow up with new friends from the MCP conference about what has been going on in that space. I am close to my AI orchestration of production hardware and hardware under test.

ADHD and object permanence is rough but I want everyone to know I care and am always excited about collaboration.

[tribal burrow]

ooh glowy things that my cats would definitely never respect

[stoic knot]

with dagger services, how do I know if they are up/down?

[stoic knot]

hmm, I see up never stops and cedes control back to the terminal, like a -d flag with docker run would allow for?

[patent slate]

Hi Team! 👋

I'm loving Dagger, but I wanted to flag a small DX papercut that causes some "WTF" moments for us. I know it's just a niggle, but it's something I think could improve DX for sure.

When running a Container.Publish(), the output stream is flooded with red ERROR logs whenever there is a cache miss for a layer (standard 404 from the registry):

13  : remotes.docker.resolver.HTTPRequest
14  : ┆ HTTP HEAD
14  : ┆ HTTP HEAD ERROR [0.3s]
13  : remotes.docker.resolver.HTTPRequest ERROR [0.3s]```
**The Friction:** As a developer, seeing a wall of red errors makes me instantly think the build failed. It's confusing to see "ERROR" used for a routine check (checking if a layer exists) that is essentially a boolean "false" rather than a process failure. It makes the logs look broken even when the publish is 100% successful.

**Suggestion:** Assuming this isn't just us doing something dumb, could these specific "Not Found" errors during registry resolution be downgraded to WARN or INFO, or handled internally without bubbling up as a full ERROR in the default log output? It would make the "happy path" much cleaner and less alarming. I've attached a screenshot of what we are seeing. 

**Context: **We run Dagger in a centralized "Build Service" to avoid granting privileged root access within our developer Kubernetes workspaces. Our CLI triggers remote builds on this service, which connects to the Dagger Engine and pipes the raw stream (via dagger.Connect(..., WithLogOutput(http.ResponseWriter))) directly back to the user.

Because we are effectively "remoting" the Dagger output to the developer's terminal, we rely heavily on the default logging behavior. We would love for the "happy path" log stream to remain clean, reserving red "ERROR" text for actual publish failures. This would greatly help our developers distinguish between routine network checks and real problems that require attention. 

Thanks for the great tool! 🚀

I'd be happy to start a Github issue, if this is considered one.

[jagged flicker]

Thank to have raise the issue, I think that's a valid ask.
Fee free to open an issue so we can track it.
My first thought would be to see if we can group them and mark them as warn, or even print a better message (saying we are waiting the image to be accessible). In this case it shouldn't be seen as an error, we can probably print them in a better way. I haven't yet looked at the code but that could be a nice improvement.

[patent slate]

Done! https://github.com/dagger/dagger/issues/11604

[cunning jolt]

I agree. Marking them as WARN and maybe collapsing them would make for a better UX. Especially in CI environments where --progress=plain or dots. Seeing the ERROR is jarring

[sharp marsh]

just replied in the issue 🙏

[patent slate]

And I replied to your reply. 😄

[stoic knot]

I left my 2¢ 😁

[cunning jolt]

I want to make a correction. It doesn't look like --progress=dots prints those spans. So that could be an alternate solution.

[stoic knot]

have you tried --progress report? I'm going to look into moving our CI over to this (parallel work has intermixed the logs on jenkins)

[cunning jolt]

I have not. Are you asking if its hidden with report? I can check tomorrow

[stoic knot]

more saying I have only briefly tried it out and curious if it is better for what you are after, I haven't tried it yet in the situation I think it could help in, so I'll have to report back next week or two

[cunning jolt]

--progress=report vs --progress=dots

[stoic knot]

This might be one of the coolest things I've done with Dagger

1. clone and build another project with a Dockerfile
2. add developer layers on to figure out why it's not working
3. create a patch, apply that between clone & build, profit!

[stoic knot]

Is there a way to control resource per session or exec? Something like: https://docs.docker.com/engine/containers/resource_constraints/

[sharp marsh]

no, not currently. ref: https://discord.com/channels/707636530424053791/1446153727881777266

[cerulean token]

is there any way to pass arguments to check functions thru 'dagger check'?

I tried using user defaults, and while 'dagger check' definitely parses my .env file, it doesn't seem to apply their values to my check function

[sharp marsh]

user defaults can be applied to checks. Have you validated that your .env file is correctly populated?

[cerulean token]

disregard: I just missed the use of my user defaults in the logs thx

[stoic knot]

@vestal creek @winter linden here's the latest with where I'm at on the CUE frontend for the Dagger Go SDK. Starting to solidify, ready to try out, love to hear your thoughts. It's def not trying to be 1-1, other concepts are blending in too
https://github.com/hofstadter-io/hof/tree/_next/examples/env

[patent slate]

@stoic knot - not to knock your work which is fantastic (and I might be missing its intentions, as I only flew over the repo quickly), but the first question that comes to my mind is, why take a highly flexible and imperative solution like Dagger and put a declarative layer on top of it? Not sure you knew this, but Dagger sunsetted its own CUE SDK in 2023. My take as to why this happened is because the language SDKs help devs avoid the declarative and piecemeal imperative mess (with bash scripts) many current CI systems have. In other words, building workflow in a declarative fashion is a PITA. Dagger went from CUE to full on language SDKs because of the declarative friction and added cognitive load CUE caused IMHO. It's the exact same declarative friction and cognitive load k8s has with its YAML manifests, whereas the "workflow" is hidden in understanding how k8s works, which is almost worse.

So, you might be building a wheel that was already built and has been tossed out some time ago for the language SDKs. Though, I might be wrong too. I really don't want to demotivate you at all. I'm just hoping you can understand why your endeavor might not gain the traction you'd expect.

[stoic knot]

I worked on the original CUE SDK, marrying buildkit & cue/flow dags was painful. This is a different take with a different goal (not an SDK, venn diagram with other things)

1. I'm probably CUE's biggest fan, this fills a big gap in my unified CUE fabric for software dev'n
2. yeah, doing dagger in CUE 1-1 is painful, but doing a subset via CUE make sense to me, there are a ton of config based workflows that can be very easily / automatically ported via config file transformation, moving to a code based alternative
3. From the devs I serve, I hear constant complaints about Dagger vs Makefile/Dockerfile, the language based setup is confusing and unfamiliar to them (despite writing the same language daily). They need something they can make minor edits to occasionally with confidence, CUE shines in this regard in the general sense, but they naturally want to use industry standard tech they know. This meets them hopefully somewhere in the middle. This gets back to my, have a unified CUE layer on everything for consistency and confidence, they can see the full AST for how their software gets built, run through CI, and served in production, all through CUE as a single lens
4. This isn't for people who already use Dagger, this is for people who prefer configuration / CUE driven service definition, building, ci'n, running, etc...

[patent slate]

I worked on the original CUE SDK,

[mild coral]

Happy New Year dagger team! 🥳
Just got back to work and looking forward to some more fun with this product!

Can see from the commit history on the main branch that you guys have been working hard over the holidays! Hopefully not too hard!

[vast mica]

Why does dagger leverage container runtimes (docker, podman, k8s, etc) to provision the engine currently?
Is it on the roadmap to run without them?

[winter linden]

It's a packaging convenience, dagger bundles a bunch of different binaries (first-party and third-party) and wiring between them. An OCI image is a convenient way to package them together.

Since you run that OCI image as a privileged container, it's essentially like a portable host service.

[winter linden]

@vast mica now I'm curious about your use case 🙂 Were you just curious, or is the OCI packaging complicating things for you in some way?

[vast mica]

I built a cli with dagger integrated and just didn't want to have to require users to have the container runtime if I didn't have to.

[winter linden]

Ah I see!

FYI there's support for remote execution. So you have the option of running the containers on behalf of your users, then configuring their CLI to connect to that remotely. The official clients (SDKs & CLI) automatically take care of streaming the client's context to the remote engines, so it's fully transparent (unlike for example Docker, where eg. host paths are relative to wherever the engine is running).

The context streaming is per-session, so you can pool a bunch of dagger engines shared by all your users (IF they are all equally trusted), and the same engine can service different clients with different contexts. The only downside is cache fragmentation.

[vast mica]

That makes sense! I’ll default to a local engine when a container runtime is available, and fall back to a remote engine otherwise. Thanks!

[stoic knot]

Where can I learn about Dagger / SBOM topics?

[sand sierra]

I've added a pull request. There are some checks failing. Is it possible for me to see what is going wrong?
https://github.com/dagger/dagger/pull/11628

When i run the tests locally with dagger call engine-dev test --test-verbose --timeout 1h --failfast the tests seem to randomly fail (also on the current main).
Probably I am doing something wrong, but i can't see it.

[stoic knot]

wait, does the pretty TUI show when "parallel" definitions of the same container are building, i.e. a base image two to building in the same sequence. I just saw the sequence of steps of steps processing at the same time and I thought double work was going on, but perhaps it is just double printing?!

or maybe it's more like a set of steps are shared between two containers, and it was clearing them in parallel, which seems super cool if the TUI is showing that

It's still definitely re-running steps that should hit the cache imho, but 0.19.8 does generally seem better about caching? hard to say, I have some manual id memoization where I upsert some pointer to dagger for a cue value that duplicates

I can give you a one liner that shows this and chews through about 50G of disk, it's not really that much, so I'm very surprised it even approaching that number, the final image is like 3G

[stoic knot]

this build here: https://github.com/hofstadter-io/hof/blob/_next/examples/env/veg/containers.cue#L31

[cursive bridge]

This is a long question so I'm gonna create a thread to save everyone reading a huge singular post. The core issue is that I'm getting this error on a few tests for modules I've written:

79 : ┆ ! failed to add directory "/home/user/work/src": failed to get rebased dir for merging: failed to add directory "/home/user/work/src": failed to copy source directory: failed to copy xattrs: failed to set xattr "security.selinux" on /var/lib/dagger/worker/snapshots/snapshots/8520/fs/home/user/work/src/go.mod: permission denied

[sharp marsh]

hey there! this has been fixed in main already. I'll go out in the next release which is expected to happen this Thursday

[sharp marsh]

ref: https://github.com/dagger/dagger/pull/11606

[cursive bridge]

Great! I was in the middle of detailing the options AI gave me and I was leading up to questions about if this was a dagger bug or something i was doing wrong. 😄

[cursive bridge]

If I deploy the dagger engine as a stateful set, then it seems like the security of the local communication used by the daemonset deployment is lost. Is that correct? I wouldn't be able to rely on node level communication and would have to do a tcp/pod/service in order for the cli to access the engine?

[icy flint]

I had claude code put together a nushell sdk: https://github.com/dagger/dagger/pull/11638
I expect there's a ton of things that are wrong, but it's meant as a starting point... I have limited time to work on it further atm, but wanted to share this, if somebody wants to pick it up and finish it, be my guest 🙂

[signal cove]

Hi, I find myself needing to debug the dependency graph of my dagger set up. I believe that this is what dagger cloud is for. My company is quite careful about who has access to the code repos though. Does dagger cloud require repo access? Is there a way to use it by running dagger entirely locally and uploading some kind of trace?

[sharp marsh]

hey Michael! the default Dagger Cloud github app won't request any specific repo permission to send traces. We only need that if you opt-in for our module insights feature as part of the team plan. LMK if you have any other questions

[signal cove]

Thanks for the response. I appreciate it. There is some kind of GitHub app involved though? Can I run dagger locally and upload a file straight to dagger cloud to get the visualisation, I need?

[winter linden]

Yes you can configure Dagger locally to stream telemetry directly to Dagger Cloud, no Github App required. The Github App is only required to unlock additional features as @sharp marsh mentioned.

[signal cove]

Ok, that sounds great. So there is limited information shared with Dagger Cloud in that instance. For some vague definition of limited 😅

[winter linden]

Yes it's a standard open telemetry stream: traces, logs, metrics. Nothing else

It's actually the exact same stream that you see rendered locally in the interactive TUI

You can press w from the TUI, and it will send you directly to a web view of the same data. Or, if you don't have it setup yet, will send you to the setup page.

[signal cove]

Sounds great. Thank you for the clarification.

[cunning jolt]

Have you looked into supporting Copilot CLI with dagger LLM integrations? I know it wasn't possible before with copilot as they didn't have an API, but it should work with the CLI right?

[warm temple]

There's some contributions in the works there but I haven't kept up with it over the holidays! But yes tldr it should be possible to integrate now

[stoic knot]

There is also new API surface in VS Code for creating chat participants and the like. It looks much easier to integrate in that way, though I haven't tried it myself (building a custom alternative and turning off all the vscode ai features.

They have a whole subsection for it: https://code.visualstudio.com/api/extension-guides/ai/ai-extensibility-overview

[cunning jolt]

Interesting, but that won't help in CI or in the terminal.

[stoic knot]

this is true, but a lot of people are in VS Code IDE /Copilot and aren't leaving for the terminal

[stoic knot]

is it an anti-pattern to have long-lived (days) client connections to the dagger engine, whereby you trigger exec, builds, and the like over a shared connection. Does that mess with sessions, OTEL, and visualization in the cloud UI?

[tribal zealot]

Requests

1. Show minute markers in the timeline.
2. Show the task duration on hover or on the task box.

[winter linden]

Hi all, we just released Dagger 0.19.9 with various performance improvements and bug fixes. If your issue recently got fixed in main, hurry up and upgrade! If not, you should upgrade anyway - it will be faster!

https://github.com/dagger/dagger/releases/tag/v0.19.9

[mild coral]

Hi Solomon! So keen to get using this ... however I just upgraded and am encountering the following error:

dagger init --sdk=go hello

! mount source: "overlay", target: "/var/lib/dagger/worker/cachemounts/buildkit2487122043", fstype: overlay, flags: 0, data:
  "workdir=/var/lib/dagger/worker/snapshots/snapshots/162/work,upperdir=/var/lib/dagger/worker/snapshots/snapshots/162/fs,lowerdir=/var/lib/dagger/worker/snapshots/snapshots/156/fs:/va
  r/lib/dagger/worker/snapshots/snapshots/155/fs:/var/lib/dagger/worker/snapshots/snapshots/154/fs:/var/lib/dagger/worker/snapshots/snapshots/153/fs:/var/lib/dagger/worker/snapshots/sn
  apshots/152/fs:/var/lib/dagger/worker/snapshots/snapshots/151/fs:/var/lib/dagger/worker/snapshots/snapshots/150/fs:/var/lib/dagger/worker/snapshots/snapshots/149/fs:/var/lib/dagger/w
  orker/snapshots/snapshots/148/fs,volatile,index=off,redirect_dir=off", err: invalid argumen

Trace available here: https://dagger.cloud/nine/traces/65c0487dc06a5b354f84f3a549a969a3#24fa906b1b3d3f5e

My docker version is 29.1.3 if that helps

[winter linden]

🤔🤔🤔 on it

[mild coral]

I'm on Mac using docker desktop.

Thanks Solomon 🙂

[winter linden]

OK everyone upgrade EXCEPT Chris

[mild coral]

yeah you should never let me upgrade

I'm the most annoying

[swift inlet]

the chown is now instant 😝 can't do it anymore ahah 🤣

[pseudo stream]

Dagger Cloud

[fossil pine]

Did something change about where the binaries are stored?

https://dl.dagger.io/dagger/releases/0.19.19/dagger_v0.19.19_linux_amd64.tar.gz gives me 403. (Not just me, GitHub as well)

[tired moth]

Why dagger team is not prioritizing highest voted feature by community?
https://github.com/dagger/dagger/issues/6990

[sharp marsh]

v0.19.19 will get there eventually Mark 😛

[stoic knot]

killer feature for Dagger, esp since you are half way there already?
https://blog.gripdev.xyz/2026/01/10/actions-terminal-on-failure-for-debugging/

[stoic knot]

It does appear they are working on it if you follow the comment / pr links. Looks like two months ago they decided the direction they were going was going to have issues related to the cache. https://github.com/dagger/dagger/issues/10895#issuecomment-3468452009

[fossil pine]

Shit

[winter linden]

@narrow nymph who wrote the POC implementation, has left Dagger, and the rest of the team has been busy on other features. We still want to ship it, it's just a resource issue. But we accept contributions 🙂

[stoic knot]

The API design seems good, my needs right now are limited to the filesystem live-sync, two-way between both host/dagger and containers within dagger, similar to the webpack use-case / optimization, i.e. let webpack handle it, I def don't want prior steps rerunning, just live fs-sync, which may be deviating from the proposal / vision you have, unclear to me.

[winter linden]

No that's in scope, we want to handle both

[stoic knot]

I need to experiment more with shared mounts between running containers, I actually need less host->dagger since I have vscode<->dagger already via an API, and I mostly want to be able to (1) edit agent code from vscode while still in the container and have it see changes the next turn (2) support collaborative agents, maybe with shared filesys, maybe with "live sync" between their containers, maybe with on-click sync, tbd which or all

[loud briar]

I'm surprised that feature is seeing any work. If you want dev containers use dev containers. I'm not sure I see the value in adding live-sync to a CI tool

[stoic knot]

I use dagger more outside of CI for other things than in my CI, at least today that's how it is

[fossil pine]

No engines available

Need...engine...will..die...otherwise 😄

[fossil pine]

I guess that's the category Dagger tried to get out of for almost a year now: CI tool. 😄

[loud briar]

RIght, but if you try to do too many things you just end up doing them all worse than a tool that does one thing well

[fossil pine]

Fair enough

[stoic knot]

Dagger / BuildKit / "container steps as a dag" is way more useful and powerful than to be relegated to CI, that would make me sad lol

[fossil pine]

I guess Claude being down makes you more sad though 😛

[stoic knot]

I don't use claude, I use gemini and it hasn't gone down ever for me, no rate limit issues either

[fossil pine]

I guess it's time to install opencode

[winter linden]

@loud briar the ability to run the same environments locally and in CI is pretty core to Dagger.

[loud briar]

Indeed, and already possible. Live sync is a development option best served by existing tools IMO, Dagger doesn't need to be everything container

[winter linden]

livesync is an interesting design problem for us. It makes Dagger obviously better when running in the local devloop. But, we have to be careful to not break the core guarantees of repeatability, portability etc. Regular local dev tools don't have that constraint (and neither does Docker, it broke the promise of portability and repeatability a long time ago at this layer)

[winter linden]

What existing tools would you say already take care of this?

[loud briar]

I don't use it personally so I can't speak to the user experience of it, but the developers I know that do use devcontainers and the vscode extension and have done so for years

[winter linden]

devcontainers is fine... So is Github Actions. The issue is that CI and local dev environments are not unified, and one of the benefits of Dagger is precisely to unify them. Inevitably this leads to overlap with both siloes. This is what we're contending with.

It's perfectly reasonable to say "I'm happy with my existing tools, I don't need Dagger". This applies to CI tooling as well as local dev tooling, to the extent that they overlap.

[cunning jolt]

Any of you managing dagger module monorepos, how do you handle automatic versioning of only updated modules?

[stoic knot]

Where I deploy Dagger, we generally want developers building their services locally in containers, such that we can guarantee the version of a compiler they use is known and part of git. This is important as the developers have to sometimes checkout release branches to make or port a fix. Prior to adopting Dagger (or local build in containers generally, we chose dagger over docker/earthly), we have release we can no longer build because the tooling was tied to the host and has incompatibility with the current versions installed.

With everything built in containers on local dev, the same way CI does, we now have more of the e2e software supply chain defined as code in git, auditable and all that for the healthcare industry

But doing so breaks certain workflows like hot-reload for react webapps, having watch would change that, we need the code inside the container to get updated, where we have the guarantees on tool versions.

[raven stag]

👋 Hi there! I've hit something with the latest release which I'm struggling to debug (and seems like a regression?) - #1460621655549411521 message
Trying to find out if I'm doing something wrong, or I've missed any release notes where I should be changing my code... 🙂

[fossil pine]

I'm playing with function caching. There are obvious cases, where i want the result cached (eg. generated some artifact).

In other cases, I'm not so sure and I wonder what other people default to.

Typical cases when I probably don't want results cached:

• Any kind of e2e or acceptance testing (even if things didn't change in theory, I still want to make sure everything works. eg. using a latest image tag)
• Publishing artifacts: don't care how many time it's called, don't be smarter than the user here. If they want to waste bandwidth, that's their right.
• Or basically any kind of interaction with external systems

How do you use/configure function caching?

[winter linden]

• e2e: after some thought I concluded it's better to cache aggressively. In the case of flaky tests, the worst that can happen is that a flaky test passes, and is cached. That doesn't affect the ability to detect and manage flakes, since that's typically done across commits. We're actually thinking about adding flake management capabilities directly in the platform.

• publishing: you should disable caching. Otherwise you may have unwanted cache hits when rolling back for example. Bandwidth waste can be handled by native tools imo

• Side effects on external systems: disable cache

[winter linden]

Related: https://github.com/dagger/dagger/discussions/11653

[pseudo stream]

These are the docs on how to configure those specific behaviors: https://docs.dagger.io/extending/function-caching

[fossil pine]

Actually, I think the worst that can happen is something changes without Dagger picking it up (although I don't know if that's possible) and things go unnoticed. Maybe these concerns aren't warranted though.

[fossil pine]

I can't seem to find any documentation on check and generate. They aren't released yet, are they? (I found the hidden command 😉 )

[winter linden]

Actually, I think the worst that can happen is something changes without Dagger picking it up (although I don't know if that's possible) and things go unnoticed. Maybe these concerns aren't warranted though.

You mean for e2e? That would be a bug in the caching system... Something we would have to urgently fix, and would affect everything equally, not just e2e

[winter linden]

check is shipped, but still experimental and undocumented (working on it...). generate is not yet shipped, but will follow the exact same pattern as check.

@fossil pine did you catch the fact that we unplugged Github Actions? 🙂

[winter linden]

We no longer have a "CI server" in the traditional sense. Just direct git-to-dagger on specialized cloud infra.

[fossil pine]

I guess it depends on the test. If it's properly contained and runs in isolation, you are right. If it has any side effects (which e2e tests often have), that changes.

[fossil pine]

Actually, @warm temple already spoilered that at KubeCon (although at that point it probably wasn't finished) 😉

But yeah, I've seen

Looking forward to giving it a try. 🙂

[cursive bridge]

Does dagger function in an air gapped environment? I know I could ship and image with the engine to an air gapped env, but my concern would be how to get the dagger modules available to the engine. Is there like an OCI/method that allows for dagger to pull the modules from someplace? Or is maybe the path here to have the dagger modules all local (via a mounted image or something) and therefore dagger doesn't do explicit remote calls for modules?

[still lagoon]

anything cool happening with the dagger cloud distributed caching?

[winter linden]

We're focusing on tightly integrated infrastructure: compute, cache, scheduler, telemetry, and execution engine, all-in-one. We determined that you can get much better performance and scale that way, when every component is dagger-native.

The end result is a complete Dagger-native CI stack.

[winter linden]

Btw @still lagoon we're onboarding test customers for early access to this new Dagger-native CI stack, DM if you're interested 🙂

[winter linden]

Not out-of-the-box, no. Airgap support is a goal that we have, and we're incrementally getting closer, but it's not something we can guarantee without some case-by-case configuration.

[cursive bridge]

I was thinking, for now can a first pass at this be having all the dagger modules location (mounted volume, whatever) and dagger just references those modules (dagger -m path/to/module call), or is there a complexity I'm missing?

[cunning jolt]

The codegen would pull in dependencies. I am not sure if dagger has full vendored dep support with Go

[cerulean token]

this might be a use case for modules as OCI artifacts ? With codegen already done as a part of the push?

though the go deps would go in $GOPATH, not in the module source, so that's funky

Guess you could put them in different layers and distinguish that way

not sure how that plays with diff SDKs though

[winter linden]

It's a reasonable idea, we've discussed it several times, but concluded that airgap support can be achieved without breaking the run from source paradigm. Adding an intermediate artifact that you have to build, push, keep in sync etc would be a MASSIVE change in our UX and DX. Imagine if Go rolled out a similar change - introducing the Go artifact registry: dependencies must now point to binary artifacts. You can use 'go push' to publish those. It would be a massive breaking change.

Instead we want to solve this in a similar way to Go and Nix. Basically: with better caching

[cerulean token]

hello! I think I found a regression in 0.19.9 pertaining to File.withName. Basically, a File from a Container renamed via File.withName cannot be used in a Container.withFile. The issue may be more widespread than that (i.e. it could be any time that you use File.withName), but I've only ran into it in this specific scenario. For example, this repro produces the following error:

package main

import (
    "context"
)

type FileWithNameError struct{}

func (m *FileWithNameError) Repro(ctx context.Context) (string, error) {
    busybox := dag.Container().From("busybox")
    txt := busybox.WithExec([]string{"sh", "-c", "echo hello > foo.txt"}).
        File("foo.txt").
        WithName("bar.txt")
    return busybox.WithFile("foo.txt", txt).
        WithExec([]string{"cat", "foo.txt"}).
        Stdout(ctx)
}

$ dagger call repro
✔ connect 0.3s
✔ load module: . 1.0s
✔ parsing command line arguments 0.0s

✔ withFileRepro: WithFileRepro! 0.0s
✘ .example: String! 1.9s ERROR
✘ Container.stdout: String! 0.0s ERROR $ 1
! failed to hard link file from
  /var/lib/dagger/worker/snapshots/snapshots/15630/fs/bar.txt to
  /var/lib/dagger/worker/snapshots/snapshots/15685/fs/foo.txt: link
  /var/lib/dagger/worker/snapshots/snapshots/15630/fs/bar.txt
  /var/lib/dagger/worker/snapshots/snapshots/15685/fs/foo.txt: no such file or
  directory

The same issue does not appear in 0.19.8. Was this expected?

[amber island]

this has been reported under https://github.com/dagger/dagger/issues/11660, and a fix is in the works under https://github.com/dagger/dagger/pull/11671

[stoic knot]

Say I have a big CI pipeline, and some of those units of work need GPUs. What's the Dagger way to handle this, such that I don't need a GPU sitting around for the entire pipeline. Let's also assume I have k8s with multiple node pools and Dagger daemon on non/gpu pools. Is there something in the Dagger SDK to facilitate? I can imagine the distributed caching comes into play here

Stepping back, BuildKit looks to have more of those k8s-y resource reqs/lims for cpu/mem/gpu. What is Dagger envisioning for this?

[warm temple]

We've talked in the past about engine "capabilities", but none of thats around at the moment afaik. But if your runners are on k8s you could pass the responsibility up I guess

[winter linden]

There's a post on our blog about experimental GPU support and how to use it

I believe there's a Container.withGPUs() or something like that in the Dagger API

[swift inlet]

Yes 💯, with only support on the Nvidia driver

[tribal quail]

Hello ! Is it possible to push tags to a git repo just using the dagger api ? or do I have to wrap that in a container etc ? I was thinking I could use the *dagger.GitRepository or *dagger.GitRef to do it but the Git API seems to be only providing read only operations

[winter linden]

Not yet, but we would like to add that!

[tribal quail]

not sure my go skills are good enough for that but I might have a look !

[mild coral]

Hey team! 🚀 I know I have had a few issues with the recent versions but on a positive note, the upgrade from 0.19.3 to 0.19.10 has cut our build times in half

That's pretty wild

Thanks so much for these improvements! They are making a huge difference 🙂

Also on my local machine, I can't believe that my mono repo runs cold 4mins BUT when cached... 27s

Thats pure bonkers

Now you just have to get it down to 2s for me and I'll be happy

😉

[mild coral]

Also thanks to .env files. I just got rid of my makefile and I'm now typing dagger call check-pull-requets

Absolutely bonkers

[jagged vault]

Hi, I wanted to ask if Testcontainers are complementary (as we invoke containers with their proper APIs directly from the tests) to Dagger E2E testing workflow, or can be replaced with the latter ?
Thanks.

[icy flint]

It would be usefull to have a "copy" button in here next to the download logs button:

[cerulean token]

Today, testcontainers can be used within dagger if you run something like the docker engine as a service and point DOCKER_HOST at it from your container using testcontainers. That's not great, though, because you lose dagger's caching, and the docker engine is a big dependency

I've been casually working on a service that implements the docker API and translates the calls to dagger, which would make testcontainers able to run in dagger "natively", but it has not been so trivial

Something I've been wanting to try that seems promising is replacing the use of testcontainers with the dagger SDK, then running your test suite within dagger with experimentalPrivilegedNesting set to true (this just lets your test process talk to the dagger engine that it's running in)

[limpid merlin]

Anyone available on dagger team

[jagged vault]

I still have to give a thorough shot to Testcontainers (currently on Dagger), and AFAIU from this lib NodeJS example, we can certainly have the same E2E tests contexts with Dagger : invoking/configuring/starting/... specific container images and exploit/connect them so that to achieve full E2E testing (even though TC feels more convenient being directly invoked from tests' suites code) 👀

[cerulean token]

even though TC feels more convenient being directly invoked from tests' suites code

the dagger SDK could be invoked from your test suites' code as well, though not with quite as clean of a DX as that testcontainers example (i.e. you'd have to build the connection URI yourself rather than just running postgresContainer.getConnectionUri())

[winter linden]

Hello, we're never far 🙂 This is our office.

How can we help?

[winter linden]

Actually Dagger has Service.endpoint() which serves a similar purpose. You can specify the url scheme as an argument, to get a ready-to-use URL

[jagged vault]

Yep. It would be neat to have some example in Docs for E2E testing (with how to correctly invoke dagger lib/cli in code and exploit it) 😉

PS: saw this usage https://docs.dagger.io/extending/custom-applications/typescript

[winter linden]

I think there are... Will look for them. Otherwise we can add more. e2e testing is probably Dagger's killer app

[mild coral]

Does this work out of the box verdverm?

[stoic knot]

It works "out of the box" for my tool built on top of Dagger, if you configure a HostDir+MountCache to do so, like: https://github.com/hofstadter-io/hof/blob/_next/examples/env/veg/docs.cue#L32
The intention is to be very limited in scope where this can happens, and to support a specific use-case (i.e. webapp hot-reload), AND to leave room to adopt what the Dagger team eventually comes up that is going to be far more sophisticated than this dirty dirty hack :]

[winter linden]

Fun Fact

In the Dagger TUI, you can type t anywhere in the trace, and get an interactive terminal in that state

[stoic knot]

really, did not know that worked when walking backwards, very neat

with all the hype around CLIs these days, Dagger's TUI traces are one of the most impressive things I've seen. Have you considered breaking that rendering out into an OTEL rendering module?

or perhaps giving devops folks a nice, general TUI OTEL command within Dagger could be a gateway drug so to speak

[winter linden]

@stoic knot well in a way, it is, since you can execute any tool inside dagger and visualize that tool's otel spans 🙂

We could ship that as a separate otelviz wrapper tool maybe

[stoic knot]

yeah, something I could point at my LGTM stack when I don't have a browser

does the TUI support custom spans? It is unclear to me if I'm doing things correctly or what I should expect to see. I should see them in Dagger Cloud yeah?

@winter linden do you have individual paid plans, I'm nearing the quota on my personal account

[sick glen]

Is Mastodon an endangered species? I see that nothing is being posted about dagger.io there

[stoic knot]

atproto has taken a lot of the mindshare that would go there, if you bridge with bluesky, you should be able to see dagger related posts? Not sure how hashtags / feeds work through, the translations are lossy as you could imagine
https://fed.brid.gy/

[mild coral]

Hey team. The .env file implementation is really good, and for the majority of cases I think its going to work. I'm just wondering if there was ever any movement towards allow you to specify the env file over the cmd line with a flag like --env-file=.env.dagger

[limpid merlin]

Plz check your DM kindly

@winter linden

[winter linden]

Using Dagger like Testcontainers

Dagger vs Testcontainers

For those of you who have asked about Using Dagger to orchestrate test dependencies from within the test execution environment (aka "using Dagger like Testcontainers") -> https://github.com/dagger/dagger/discussions/11710

[jagged vault]

Some questions I wonder :

1- Why not add the Dagger SDK as npm package to TS project (import the Dagger SDK to create a Dagger client, which provides an interface to the Dagger API), instead of a module having a client core in .dagger/sdk folder. Is it only in order to ensure better performance and compatibility with all the runtimes ?
https://docs.dagger.io/reference/configuration/modules#bundled-or-vendored-sdk

2- Difference between TypeScript Custom Application and Daggerised project (with dagger init) ?
https://docs.dagger.io/extending/custom-applications/typescript

[mild coral]

@obsidian lake @icy plaza the approach being discussed here would be quite useful for component tests. As we have discussed we want to move away from running component test dependencies in kube, and have one way to run them in both CI and locally. Today we can solve this usecase with dagger by spinning up dependency services and then running the test, in a dagger session. This would require a developer to issue a dagger command such as dagger call component-test locally. In CI, it would bundled with our check pull request or potentially its own dagger "check". The approach being discussed here however would allow the you to call the test using the language tool runner directly, then the test would interact with the dagger api to spin up dependencies. This would be a nicr user experiencing, and the user wouldnt even be aware they are using dagger.

[sharp marsh]

1. We started doing the work on this some time ago but we paused it given the amount of effort that requires specially since we want to support the same pattern in all the SDKs. Some other external contributors have requested and started to work on this for the Go SDK recently (https://github.com/dagger/dagger/pull/11547) which brought back the interest to do it for the rest of the SDKs. @wispy tapir and @jagged flicker will probably have more updated information about this.

2. Custom application = not using modules, only the typescript SDK directly which means that dagger won't provide the TS/node runtime for you
   dagger init (AKA dagger modules) has all the goodies of reusable modules + better UX/DX given that the TS/node runtime is already provided by dagger.

Most of Dagger users generally use modules. Custom applications are generally best suited for big companies and teams building custom internals tools that usually "wrap" dagger in some sort of way

[stoic knot]

I've built a custom app that goes a step further on both sides

• dev time docker-compose like experience with hot-reload
• (similar) our devs and ci run the same commands to build/test/lint/package (diff) we do this through a custom cli, not existing tools or harnesses
• deploy time, order tf/helm applies
  I'm a Go SDK user and am generally a fan of delivering a custom tool for internal devs designed around the company processes. I've been working lately to turn that concept into a general tool that still supports this vison for dx: https://github.com/hofstadter-io/hof/tree/_next/examples/env

I've built a few wrappers at this point, happy to expand or answer any questions.

[wispy tapir]

@sharp marsh already answered but I’ll add more context

First of all: yes it’s mostly a matter of performances.

Downloading the dagger library for every module would lead to loss of at least 5 seconds on cold cache call because of the download.
However, we are already bundling a compiled version of the dagger library, generated in core/index.ts.

So in theory, we could bundle the released library inside the engine and copy it in the local node_modules, we don’t even need to also copy the lib’s dependency, the LSP would be able to provide type completion with just the dagger.io/dagger package.
That solution could solve the performance issue during the generation.

However there’s 2 issues that would happen:

1. Inside the runtime, we would still need the full library with all the dependencies to execute the module, these should not be downloaded because it would create too much performance lose. So we would still need to keep the current behaviour inside the runtime, by using the compiled library. That would lead to a difference of state between what’s locally and what’s inside the runtime. It’s not a big deal but it may result in unpredictable behaviour if the version’s mismatch + that would require removing the dagger.io/dagger dependency from the module’s package.json inside the runtime which would invalidate the cache on every run because then the installation step would also be invalidated. If instead we copy the complete node_modules, then we risk version’s conflict if you also install one of the dependency in your own package.json which could also cause unpredictable error.

2. dagger.io/dagger is currently the import path for the local library. So if we use the published package then what will be generate the module import path? That would result in a breaking change.

Overall, I’m not sure the change is worth it until these 2 issues are resolved.
I’m open for suggestion though, it would indeed be super neat to use the published library to use the core bindings and simply generate the dependency bindings 😁

[jagged vault]

I more or less understand the challenge we're facing with an all-in-one bundled package. I'll keep going with module as the Doc. suggests for perf.
I was thinking that a simple diagram could be useful to mentally figure the Dagger concepts (like the one with Kubernetes Doc.), if possible : runtime, engine, SDK, core, module, cache, package/library, app... 🙂

[limpid merlin]

Anyone can tell me dagger have any responsible disclosure policy's or bug bounty program?
@winter linden

[sharp marsh]

hey @limpid merlin I've replied here. #1461399612572172633 message. Please reach to [e-mail]

[cerulean token]

Why would the 2nd of two consecutive execs routinely be a cache miss if the 1st was a cache hit and both have passed previously? Does Dagger ever skip caching a certain exec because it would take too much disk space? ref: https://github.com/frantjc/sindri/blob/e1826d7c349e469fa7bbc0856e9affc4207767d1/modules/steamapps/steamcmd.go#L115-L116

[tropic stream]

Hello all, just wondering if someone could review my pull request here (sorry if that bothered a bit)
https://github.com/dagger/dagger/pull/11605

[tribal quail]

Absolutely love the traces / logs toggle on dagger cloud !!

[sharp marsh]

merged! thx for the contribution!

[tropic stream]

My pleasure:) thx for your time on reviewing!

[mild coral]

Hi guys. At Nine we will soon be moving away from our dagger mono repo and splitting it into separate repos. This will allow for more focussed working.
One of the things that will be essential to this move is having renovate bot support, to allow us to upgrade dagger module dependencies in the dagger.json. Are there any plans to get something like this working?

Also I am wondering how close we are to being able to "check in" the generated code. This is going to unlock renovate support for regular go module dependencies - we won't want to update the ones managed by the go sdk, but we often import other packages and would want to update those.

[winter linden]

I think that should work today. We have a PR open to do it for our own repo.

[mild coral]

Very nice

Is there anything in the works for renovate support... we may have to home cook something otherwise

[winter linden]

Nothing in the works on our end. I'm a little worried at the idea of renovate messing with a platform it doesn't understand... But I don't really know much about renovate, so maybe my worry is overblown. Just pattern-matching from past experience with other enterprise gatekeeping tech

[mild coral]

Fair enough, in that case our team will probably look at developing something ourselves. Most likely we will scan known repos that have dagger modules for their git tags, and use that as a datasource.

Does dagger cloud have an API by any chance that we can use for querying modules and their versions ?

[winter linden]

Renovate + Dagger

[fossil pine]

@elfin frigate is it possible to supress errors when using dang? (ie. get a directory from a container even if withExec failed)

[elfin frigate]

ah i think you'd want withExec(expect: ReturnType.ANY) there, which should prevent an error from being raised. dang currently doesn't have any error handling (TODO 😅)

(you'd need that anyway for .directory to work - you can check .exitCode to determine whether it failed)

oops, expect:, not returnType:

[fossil pine]

cool, thanks!

BTW, I really like it so far. Very intuitive apart from a couple of things:

• pub vs let: just removing pub didn't work, wasn't obvious I should use let
• container, directory also a bit weird. I'm used to dag. (though I mostly use Go, not sure how it works in other languages)

On the bright side, I like the fact that my "CI" is dagger.json and a dagger.dang file.

Pro tip for anyone trying to try dang (while waiting for docs):

• give the grammar to Claude: https://github.com/vito/dang/blob/eff4dc7e590b4ac823285c0e6c51332bc4385672/pkg/dang/dang.peg
• check the stdlib for functions: https://github.com/vito/dang/blob/eff4dc7e590b4ac823285c0e6c51332bc4385672/pkg/dang/stdlib.go

Ah, this is another challenge 😄

Rust is fked up on my machine right now, so I can't install the extension in Zed as dev extension

[elfin frigate]

ah yeah that's annoying 😭 - I'll look into publishing it, maybe they'll accept the extension to the marketplace

[elfin frigate]

re: 1 - I'll chalk that up to lack of docs for now, sorry about that! Does it make sense now that you know how it works? (let declares private in nearest scope, pub is the same but public, = without either reassigns, like in a loop / conditional)
re: 2 - you may be interested in https://github.com/vito/dang/pull/9 - it adds import Dagger which you can then use like Dagger.container, while still providing its imports into the default namespace like how it works now. Still on the fence on whether to merge it though, there's an argument that it makes the language feel less embedded

the original goal was to provide a way to disambiguate, e.g. if your type defines its own container field, which is fairly common, and you need to call the original Dagger.container in its implementation

[fossil pine]

1. Yeah, it makes sense. It's just unusual. At least I haven't seen this before.
2. Cool!

container(platform: "linux/amd64")

How do I do this?

It complains: cannot use String! as Platform

But there is a test that suggests it should work: https://github.com/vito/dang/blob/eff4dc7e590b4ac823285c0e6c51332bc4385672/tests/test_scalar_input.dang

[elfin frigate]

oh, i just fixed that yesterday

might need to bump?

[fossil pine]

yeah, I just copied a commit hash from somewhere

it works

[elfin frigate]

glad you like it overall! lemme know if you have any feedback / blockers

[fossil pine]

the biggest blocker is the lack of editor integration 😛

but that's partly on me. need to fix my global rust install. whisper nix

Agents.md:

# Agents

## `.dang` files

When editing `.dang` files:

- learn the [grammar](https://raw.githubusercontent.com/vito/dang/refs/heads/main/pkg/dang/dang.peg) first
- look at the [stdlib](https://raw.githubusercontent.com/vito/dang/main/pkg/dang/stdlib.go) implementation
- look at the [test suite](https://github.com/vito/dang/tree/main/tests) if necessary

Do NOT try to look for resources or documentation elsewhere: you won't find any. Use only the provided resources.

My first dang module: https://github.com/sagikazarmark/tus-compliance-tests/blob/main/dagger.dang

[elfin frigate]

nice! small tip: you can set *.dang linguist-language=GraphQL in .gitattributes to get reasonably good highlighting, e.g. https://github.com/vito/dang/blob/eff4dc7e590b4ac823285c0e6c51332bc4385672/.dagger/main.dang

[fossil pine]

ah, cool.

It took a bit longer than I expected. I had to fight with the syntax checker (or rather the lack of it). I used this PEG library before and this is a huge pain with it. But I have to admit: I'm not very familiar with graphql either.

One particular bit almost made me give up: enums have to be al capital letters. 😄 That one took a good 10-20 minutes, because it appeared as a syntax error with the usual PEG error message. I noticed the regex pattern at the very end of my terminal by accident.

Other than those type of issues, it felt intuitive. Very similar to rust, so it's familiar syntax. (Except case vs match)

My CI is now two simple files in the repo root which feels very neat and clean.

[fossil pine]

May have found a UI bug on cloud

[chrome moss]

Hey all, I think I may have ran into a bug/regression and wanted to check it wasnt me/something intentional. I've got a ruff fix function that returns a changeset, and I get ! internal error: Directory.diff received different relative paths: "/" != "/app". Relevant code from: https://github.com/act3-ai/dagger/blob/main/python/ruff.go#L57

ctr := r.Python.Container().
        WithExec(args)

afterChanges := ctr.Directory("/app").Filter(dagger.DirectoryFilterOpts{Exclude: []string{".venv", ".ruff_cache"}})

return afterChanges.Changes(r.Python.Source)

I take a src, add it as a work directory "/app" to a python/ruff container to run fix against, then want to return the changes it made against the source originally given.

[winter linden]

yes I believe that is a known issue. I've run into it myself.

[winter linden]

@chrome moss here's an example of fixing it with a workaround: #1439710300701196499 message

[chrome moss]

Thanks, excited for what yall cookin up next release

[elfin frigate]

May have found a UI bug on cloud

[cursive bridge]

I'm running the dagger engine on kubernetes, and initiating a pipeline via a gitlab-runner and the dagger-cli. The docs talk about running dagger with elevated privs which is what i do, but I started wondering if the cli needed elevated privs too. After all, it is talking to the engine which is doing all the work. I thought maybe the cli could run w/o elevated privs. However, it appears there is some process at the end of a cli call that does need elevated privs. I get this error:

ERROR ✘ export directory / to host /builds/... 0.0s ERROR ! error from receiver: error setting dir metadata for /builds/... lchown /builds/...: operation not permitted

Is this expected? If so, what is the cli wanting to do that needs elevated privs?

[winter linden]

The CLI doesn't intrinsically need elevated privileges. If it gets an error trying to write in /builds, it's probably because it tried to export files to /builds (either because its working directory is inside that path, or because that path was passed explicitly as a CLI argument).

Either that, or the error is actually coming from the engine?

Also just to clarify: the path /builds doesn't mean anything in dagger, it seems like a path that is specific to your CI environment

[cursive bridge]

Ya, I'm pretty sure the the /builds is related to our ci environment. And I looked closer and it does appear that error is coming from the engine. That's odd, as I didn't used to have that error. I had only changed the cli container permissions. I'll dig into this more.

Thanks for confirming that the cli shouldn't need elevated privs.

[pseudo stream]

I suspect the client is trying to do a chmod/chown of a parent directory of some path you are exporting, probably due to it trying to make the local dirs exactly match what's being exported from the engine.

I'd probably consider it a bug for dagger to error out there (though it's kind of a tricky situation since there are rarer cases where you very much do want directory owner/perm to exactly match), so if you have time to open an issue that'd be appreciated

[mild coral]

codegen not dertministic on 0.19.10

Hey team. I am very keen to start checking codegen for our monorepo. However I seem to be getting some random diffs everynow and then.

The particular diffs I am getting are around the placement of MarshalJSON() and UnmarshalJSON() for a particular module type I have in one of my go modules.

Is this a known issue? If not, I can provide some source to reproduce.

^ its basically shuffling those two functions around.

I should note that they are receiver functions of a type which is not the main module type.

Remote is something we return from our module

GitRepo is the module type

// Remote - returns the git remote
func (g *GitRepo) Remote(ctx context.Context) (*Remote, error) {

[winter linden]

Hi Chris, the next release will include a recently merged fixed to codegen determinism. I would be curious to know if your issue is fixed in main?

The fix: https://github.com/dagger/dagger/pull/11579

[mild coral]

Yeah will test it out tomorrow

[warm wagon]

Question around best practices: for a company wide "place" for our modules to land, is it usually just in a repo like "github.com/co/dagger" where each dir is its own module? I also see people doing "github.com/co/daggerverse" like Mark: https://github.com/sagikazarmark/daggerverse

[cunning jolt]

This is what I do in my workplace too. I have a "daggerverse" repo which is internal (open to any dev) but not public (external)

[winter linden]

@warm wagon note that it can also be a subdirectory in your monorepo, it doesn't have to be a dedicated repo. It's whatever fits your workflow best.

[cunning jolt]

Good call out. We have both in fact.

[warm wagon]

Yeah, I have some existing CI/CD modules in our monorepo’s ‘.dagger’ - more curious how to effectively share across engineering little AI utils I’m writing with Dagger - so not really CI, more CLI

[cunning jolt]

For this, a central repo is the best IMO. Easy for anyone to share and use

[winter linden]

this could be a good fit for the experimental "toolchains" feature. It lets you install modules as user-facing utilities directly in a dagger project, and unlike regular dependencies, their functions are immediately visible to end users, and execute in the context of your project.

[torn wren]

If I try to install a module that has a toolchain as a dependency it does not work. Is this a valid thing to try? I can give more info but wanted to see if what I am trying was even allowed first.

[elfin frigate]

what do you mean by 'it does not work'? what happens?

[torn wren]

The dagger.json does not change and the output looks like this

$ dagger install ../../pyfoo/
✔ connect 0.3s

✔ moduleSource(refString: ".", requireKind: LOCAL_SOURCE): ModuleSource! 0.1s
✔ .configExists: Boolean! 0.0s

✔ ModuleSource.localContextDirectoryPath: String! 0.0s

✔ moduleSource(refString: "../../pyfoo/", disableFindUp: true): ModuleSource! 0.3s
✔ .moduleName: String! 0.0s

✔ ModuleSource.withDependencies(dependencies: [xxh3:7976a95cace6e83d]): ModuleSource! 0.0s
✔ .withEngineVersion(version: "latest"): ModuleSource! 0.0s
∅ .generatedContextDirectory: Directory! 10.5s

[torn wren]

when I bump up the logging I can see this:

∅ .generatedContextDirectory: Directory! 1.6s
╰╴∅ load dep modules 1.6s
  ╰╴∅ ModuleSource.asModule: Module! 1.6s
    ├╴✔ load dep modules 0.0s
    ╰╴∅ module SDK: load runtime 1.6s
      ╰╴∅ PythonSdk.moduleRuntime(
        │ ┆ modSource: no(digest: "xxh3:2721db70914d6ba6"): Missing
        │ ┆ introspectionJson: no(
        │ ┆ ┆ digest: "sha256:733ff8655c5c24fe4ba01594ae2b1f10c5566fe23dbb95cc34f7662be59da2d5"
        │ ┆ ): Missing
        │ ): Container! 1.5s
        ├╴✔ load sdk runtime 0.0s
        │ 
        ╰╴∅ Container.from(
          │ ┆ address: "docker.io/library/python:3.13-slim@sha256:51e1a0a317fdb6e170dc791bbeae63fac5272c82f43958ef74a34e170c6f8b18"
          │ ): Container! 1.5s
          ╰╴∅ resolving docker.io/library/python:3.13-slim@sha256:51e1a0a317fdb6e170dc791bbeae63fac5272c82f43958ef74a34e170c6f8b18 1.5s
            ├╴✘ remotes.docker.resolver.HTTPRequest 0.1s ERROR
            ├╴✔ remotes.docker.resolver.FetchToken 0.1s
            ╰╴∅ remotes.docker.resolver.HTTPRequest 1.3s
              ╰╴∅ HTTP HEAD 1.3s

[elfin frigate]

seems like it's trying to add the dependency, at least - it's expected to work, the toolchains should just be invisible to the depending module. cc @warm temple if you have any ideas

[warm temple]

yeah I would expect it to work too. Let me see if I can repro really quick

Got an engine panic 😱 I'll work on a fix! Also, the install kind of silently fails. It gives exit code 1 but doesn't actually show anything out of the ordinary. So unless you have your shell set to show the previous commands status and also pay attention to that, you wouldn't catch it

[torn wren]

thanks for looking into it I will stay tuned

[winter linden]

@torn wren any thoughts on the toolchain feature so far? (besides this crash 😅 )

[torn wren]

It has enabled one specific use case for us and that is good. As a platform team we wanted a way create a "pipeline" module build with many other modules that we have developed. We did this with normal dependencies and that was ok for some users that were happy with the out-of-the-box workflow that we created for them. But we wanted to give our more advanced users access to the underlying modules so they could go off script. Building the pipeline modules with toolchain dependencies has allowed these users to extend their local module easier and without having to reach out to the platform team. This has worked well so far.

[winter linden]

Nice! I'm curious if toolchains might be useful for less advanced users too, since it requires less boilerplate to be dropped in the end user's project (something we hear frequent complaints about)

[torn wren]

Now that you say that maybe advanced vs less advanced is the wrong characterization. We just wanted to lower the bar for users that want to modify and extend their local module. I guess the toolchains make it easier for all users alike to do that. So yes, I can see that.

[winter linden]

FYI I foresee a future where you no longer need to write code in your local module - instead all dagger functions are implemented in toolchains. And project modules are just a naked dagger.json (no more .dagger). This is not a breaking change in how Dagger works: more of an ongoing discussion on what kinds of best practices become possible with toolchains

Basically a zero-boilerplate world

We're experimenting with that in our own repo (github.com/dagger/dagger) if you're curious

[warm temple]

here's the fix! https://github.com/dagger/dagger/pull/11753

[torn wren]

for me the local module as a place that the user can implement project specific logic. I don't see how that would be useful as a function in a toolchain given that it applies to only one project. But I am making the assumptions that the platform team creates the toolchains and devs install tool chains and maintain project specific logic in their local module. I will take a look at your link and maybe it will make more sense. I feel we are probably thinking of different use cases, maybe.

[winter linden]

Yeah that's basically the ongoing discussion: how specific should we allow toolchains to become. Plenty of lively and insightful debates on this topic 🙂

In the case of our own repo, we needed a way to break down the entire set of dagger functions, into logical components. Initially we broke it down into sub-modules: one sub-module for the CLI, one for the engine, one for each SDK, etc. Each with its own dager.json and .dagger

The problem we ran into, is that logical components in don't map cleanly to a single repo. In fact as soon as you have a monorepo, everything gets entangled, it's kind of inevitable... So the location, and sanbdoxing, of those sub-modules became somewhat arbitrary.

Switching to a collection of toolchains, all installed in a shared module, was a nice improvement. Each toolchain can access any files it needs anywhere in the project (with appropriate filters). Some toolchains are very reusable; some super project-specific. Generally everything trends towards more generalization over time, but it's flexible. I quite like it.

[chrome moss]

Some feedback on this fix makes me question what I thought would be a nice future feature of toolchains if I am interpreting it correctly. Right now, toolchains are limited to being individually installed. A user can set a single namespace for them, but that puts the onus on the user to track what could be many installs, along with keeping their versions up-to-date on release. It also puts a bind on them when they want to combine things(think of a lint all function)), then they would need to do that themselves in .dagger folder locally.

An idea we originally tried when toolchains were released was to create a "ci" module that has toolchains installed to that (build, python tests/lint, general lint(markdown, etc). From there, we could tell users to install a single toolchain - ci, and that brings along all the associated toolchain calls for them already. From there, the ci module could contain additional functions if needed(like lint all). The main goal there though is a user gets a single install that is versioned, and is able to see every tool they have available right from the CLI, on top of niceties built by a platform team.

[winter linden]

In combination with toolchains, we're adding first-class support for some of the "niceties" you mention. For example a first-class concept of "checks": dagger check -l to list check functions, dagger check to call them all (optionally filterable). This makes a whole class of aggregator functions, which each project module would otherwise need to develop, unnecessary.

We're going to add more of those special niceties, built on the plumbing of dagger functions:

• dagger generate: call all functions marked with +generate, and propose a diff to apply locally
• dagger up: call all functions marked with +up, collect the services they return, and run them locally with port forwarding
• etc.

The key is that dagger will take care of aggregation, and present a user-friendly interface to it - removing the burden of writing aggregation functions

If you want to see a prod-scale usage of this pattern: dagger -m github.com/dagger/dagger check -l to list all checks available on our repo right now

dagger -m github.com/dagger/dagger check '**:lint' run all check functions, across all toolchains, named "lint"

[warm temple]

in addition to what Solomon said, we've also talked about ways of letting toolchains bring along other toolchains. I don't see why we wouldn't want to enable that! Currently you could have a blueprint with a bunch of toolchains, but that's slightly different

[winter linden]

But, there's still a question mark on what it means for a toolchain to have toolchains - per discussion with @elfin frigate. If we mean toolchains as "dev dependencies", then your toolchain's toolchains would not be visible to you 🙂

[warm temple]

right, I think it would be something more explicit than just a toolchain's own toolchains

basically some way to have a config that says "i'm just a collection of toolchains"

[winter linden]

Ah yes, blueprints are the complementary features: when, even in spite of the reduced need for aggregating functions, you still need to be in control of the project's full config - basically you want to fully centralize the configuration of multiple projects using a centrally developed template. You can use a blueprint for that.

[chrome moss]

We tried blueprint originally, but you can't have an SDK when using it. I understand the goal of wanting to remove that entirely, but in our case it seemed the best way to let users make modifications they need without involving us. Trying to create aggregate and/or generic commands for those purposes becomes very difficult quickly and starts leading to this ever-expanding scope creep. Our goal is to simply say, "here a ci module you install, you can see every function/tool available with dagger functions", and then provide a small set of sample commands with the ci install in their .dagger folder. Using lint all as an example, they could see in code exactly how it looks written, and if they dont want to run ruff, or need to exclude a path from its linter, just come in here and add a line (or remove it it entirely if they dont want to run it at all) instead of a us(platform guys) having to try and fit every niche requirement into modules that makes it become too unweidly/complex. I hope that makes sense

We took advantage of checks immediately btw. Absolutely goated feature

[warm temple]

Makes sense! I guess it depends on how much overlap your projects have too. What we've been working towards with toolchains is making a lot of very specific toolchains, that way you dont have to worry about making the code so flexible it becomes useless, and also you can integrate better with the underlying tool. So a good example would be a ruff toolchain. And then for project specific needs, toolchain customizations can come to the rescue for project specific flags or filters that are needed. But if your teams are happy to do some customization on a template you provide, that sounds like a smaller piece for you to support compared to a number of toolchains

[chrome moss]

By customization I assume you mean in the dagger.json. A question I have for you here is how would this handle something like chaining? Currently we utilize With* functions to handle things like private registry auth or adding env variables. so in our case a standard call would be dag.python().ruff().lint(). but if they have a private package that needs auth, it would be dag.python().WithIndexAuth().Ruff().Lint(). This was a much cleaner way for us to implement common things without having to reitirate flags repeatedly in individual models/functions

[warm temple]

Yeah exactly, in the dagger.json. In that case ideally I'd have the registry auth as an optional part of the constructor rather than using a builder pattern. And then if those parameters are secrets you can pass them with user defaults (.env)

[winter linden]

Yeah and you can still keep the builder pattern in the underlying functions. Constructor + discrete arguments is most useful at the last mile (toolchains) where you want users to get out-of-the-box checks and other simple functions, customizable with simple config, rather than with custom code

[chrome moss]

ahh, if providing parameters for the contructor is a part of the customization, then thats just as good. Is this something you've already released I can try out?

[winter linden]

Yes, although you have to manually edit the dagger.json for now: https://docs.dagger.io/core-concepts/toolchains#advanced-customizing-in-daggerjson

[chrome moss]

Perfect, I'll give it a whirl. Thanks for the help/info, its great to be able to see where your heads are at. As a funny side note, I had to look at a gitlab-ci pipeline I wrote a while back and it was like staring at hieroglyphs. I cant believe I used to write/manage that.

[winter linden]

Thanks! That's encouraging 🙂 The feedback is very appreciated. I am hopeful that when the dust settles on this sequence of design changes, everything will be simpler for newcomers, without sacrificing customization for power users

[mild coral]

Hi Solomon. Testing on dagger from the main branch, I am still encountering the issue.

[mild coral]

So a few things... the linked pr was merged last year so i think it was already in 0.19.10

The issue seems to be affecting the placement of MarshalJson and UnmarshalJson in the generated code

But only for one type which is the main module type but a another struct type that one of my module functions returns

[winter linden]

Would you mind filing a github issue? 🙏

[mild coral]

Can do

Fraid it will have to wait until tomorrow as I have run out of time

But yeah happy to tomorrow

[loud briar]

Has there been any progress on hiding stdout? The last discussion on this was about fetching aws ecr auth and it showing in the stdout with some hacky workarounds to prevent that

On that same topic, any thoughts on being able to hide Dagger output but not user output? --progress options aren't ideal, they hide both Dagger output and user output

[winter linden]

@elfin frigate not sure if this is in scope for your ongoing UI sprint, but just in case 👆

[winter linden]

What do you mean by "user output" in this context?

[loud briar]

Any form of print output from my module

My Gitlab logs are 90% dagger output 10% mine, and it's been highlighted by users that we need the 10% and the 90% is just in the way

Engineers writing modules want that 90%, users using modules don't care

[winter linden]

Yeah we were just discussing that with @elfin frigate the other day, we're all in agreement that default output should be user-defined spans and logs. The issue has been having a clean way to filter them in the otel stream. We agreed to use a otel span attribute for that. Should be straightforward implementation now (I think), just a matter of backlog priorities now

[loud briar]

Great, will keep an eye out for that. There's some hesitation to roll Dagger out further whilst users are being confused by logs they don't understand so this is important for us

[azure hatch]

Does anyone have any experience running Dagger Functions on k8s? Was kinda wondering how well the cache works there

[cursive bridge]

Quite well actually. We have our test for dagger modules running on a dagger engine deployed on kubernetes. 1st time after engine starts it can take about 10m for all our tests to run, subsequent runs 1-2m for PR/MRs/merges.

[winter linden]

In case you're interested: we started beta-testing hosted engines in Dagger Cloud, with scale-out compute & cache persistence, vertically integrated for maximum scale and performance. If you ever want to evaluate an alternative to self-hosting on kubernetes, or if you want to benchmark your solution 🙂 Just DM me for details.

[mild coral]

Hey guys. Having some more host file caching issues... it would seem that files of the same name are potentially getting swapped in certain circumstances. Might be good to jump on a call with you guys to discuss as I think it will just be easier to share screen and talk through the issue

[mighty flax]

Hey. Doing another presnetation of dagger next week at Aix-En-Provence, France so I'm finalizing stuff. Just checking you know if a function returns an array of object. Then you could call dagger call tests-matrix phpunit which will call the function phpunit foreach object that is returned by the tests-matrix function. I wonder why it is not possible to have all those cases be ran simultaneousnly ? Or maybe I missed an option somewhere ?

[jagged flicker]

By simultaneous you mean to have them running in parallel by default? If so, it's not possible by default, you have to do it directly in your module.
We have in progress work on test splitting and dynamic checks, to allow automatically group tests and run them in parallel for instance. But it's not yet finalized.

[mighty flax]

too bad. I am using PHP and doing parallel work is very tedious ATM. I was hoping that all languages could benefit natively from coroutines or something similar.

[winter linden]

Like @jagged flicker said we are working on parallel execution across machines. But what you're doing (fan out across objects in an array) should already work concurrently on the same machine. Unless there's a bug forcing sequential evaluation.

Which one were you asking about?

[sharp marsh]

yep, it seems to be doing it sequentially

[winter linden]

This is a known bug... https://github.com/dagger/dagger/issues/7353 If anyone is looking for a side quest 🙂

[mighty flax]

thanks 🙂 this is what I meant 🙂

[elfin frigate]

https://github.com/dagger/dagger/pull/11764

[winter linden]

you're in luck @mighty flax 🙂

[mighty flax]

ahah that is awesome ! Sorry couldn't do it myself but I need to learn go...

[elfin frigate]

@winter linden does fixing this potentially mean simplifying the checks API? iirc CheckGroup was added as a workaround initially

[winter linden]

CheckGroup was not a workaround for concurrency - @pseudo stream just happened to take advantage of it to implement check-level scale-out.

If I remember, it started out as a place to attach include/exclude: "give me all the checks matching these filters"; "now list and/or run them"

That said I'm all for simplifying APIs if we can 🙂

[pseudo stream]

Scale out works on individual checks, there’s no dependency on the check group thing

[elfin frigate]

ah ok, i just remember at the offsite you hit the stepladder non-parallesm thing and thought I remembered you saying you worked around it by adding a type that handled the parallelism internally

[winter linden]

Yeah but if I recall, CheckGroup.run() is the entrypoint for scale-out. Then it farms out individual calls to Check.run() to other engines? That's what I meant but maybe misremembering

[pseudo stream]

That’s because it’s the only entrypoint to running checks from the cli. If the api was an array of checks instead of checkgroup that would work the same for scale out

Just saying if you want to change the api like that scale out has no attachment to it

[winter linden]

Roger that 🙂

[pseudo stream]

Hey guys. Having some more host file

[elfin frigate]

Any form of print output from my module

[fossil pine]

@elfin frigate is it possible to organize dang files into "modules"?

Use case: I have a fairly complex docker bake setup for a project that builds dozens of container images. The complexity comes from the fact that a lot of images are built with different root images (context is replaced to different root images) and there are lots of images.

The challenge with this bake setup is that each bake definition is in a .bake directory in the repo (otherwise sourcing all bake files, especially with all cross-dependencies would be a nightmare). Would be nice to move build instructions to the actual module in the project.

So I was thinking maybe I could rewrite it in dang if it supported loading dang code from other places in the same repository.

Is this something that dang supports? Or could support?

[elfin frigate]

dang modules

[fossil pine]

Does dang support the Go SDK's With method?

doesn't seem to, but maybe I'm doing it wrong

[wind roost]

Hey, will there be any Dagger Hackathon at KubeCon EU this year? really enjoyed it last time

[warm wagon]

So when are the dagger hosted caches coming around? GitHub actions are brutal without the caching 😂

[winter linden]

Better: Dagger-hosted integrated cache, scheduler & compute 😁 We unplugged Github Actions completely for our own CI.

Want to try ?

Slapping a remote cache on dumb compute is a band-aid at best. Buildkit had remote cache export all this time (and we support it) but it never was enough.

[warm wagon]

Would love to: we just open sourced a new tool, all in on Dagger. But Nightly / CI builds take like 5+ mins, I think most of it stuck in the go mod download layer

https://github.com/papercomputeco/tapes/actions/workflows/nightly.yaml

[winter linden]

DM me & I'll share the details! It's still experimental but maturing quickly.

If you look at the checks on our github PRs, it's all dagger-native CI running it

[ancient ivy]

Hi solomon, do you can control the process with reprocess a function or trigger?

[winter linden]

Yes you can re-run from dagger cloud. You can also use your CI infra for remote execution & cache of your local runs (with your local credentials)

[ancient ivy]

Amazing, but how?

[winter linden]

end-to-end control of the CI stack: compute, cache, execution engine, git events, telemetry, scheduler.

[mild coral]

Hey guys would there be a way to mark a function as a check and error on it if the required parameters werent present to run the check? Use case: we want to run checks in CI but dont want to run the risk of checks silently being omitted due to misconfigurarion

[ancient ivy]

Could you send me a example with rerun a specific function? Thank you

What Everyone think about a project of a complete ci/cd ui with blueprint idea, like as n8n to dagger? I thinking about this project

[cursive bridge]

I am planning to test this idea, but can you share data between dagger invocations by sharing a cache volume? Say I have one module that builds a binary and another that takes that binary and creates a container. Usually I would have a the build function return the output of the build, copy that to the host machine, then pass in the copied binary to the module that creates a container.

Instead of copying the binary to host, could the binary be stored in a cache volume (CacheA) by the build module and then that same cache volume (CacheA) in the container module? This would allow passing data between modules w/o having to copy/store on the host.

Next question is if this is allowed, SHOULD it be?

[mild coral]

Not sure why, but I tend to see a lot of these errors when running dagger develop -r in our repo:

! failed to sync: conflict at "modules/config": change kind changed from "delete" to "add" during sync

Rn I have a branch with the code checked in. When I jump between that and the main branch, I tend to see this error pop up frequently for a number of our modules

It does not persist however... just re run the command and we're good.

Just wondering if this is a known issue

Another thing... when restarting my computer ( which I do daily ), I tend to see a bunch of these errors on my dagger engine the next day:

! failed to mount /tmp/buildkit-mount795826261: [{Type:overlay Source:overlay Target: Options:[workdir=/var/lib/dagger/worker/snapshots/snapshots/177/work upperdir=/var/lib/dagger/worker/snapshots/snapshots/177/fs
  lowerdir=/var/lib/dagger/worker/snapshots/snapshots/171/fs:/var/lib/dagger/worker/snapshots/snapshots/170/fs:/var/lib/dagger/worker/snapshots/snapshots/169/fs:/var/lib/dagger/worker/snapshots/snapshots/168/fs:/var/lib/dagger/worker/snapshots/snapshots/167/fs:/var/lib/dagger/worker/snapshots/snapshots/166/fs:/var/lib/dagger/worker/snapshots/snapshots/163/fs:/var/lib/dagger/worker/snapshots/snap
  shots/161/fs:/var/lib/dagger/worker/snapshots/snapshots/159/fs volatile index=off redirect_dir=off]}]: mount source: "overlay", target: "/tmp/buildkit-mount795826261", fstype: overlay, flags: 0, data:
  "workdir=/var/lib/dagger/worker/snapshots/snapshots/177/work,upperdir=/var/lib/dagger/worker/snapshots/snapshots/177/fs,lowerdir=/var/lib/dagger/worker/snapshots/snapshots/171/fs:/var/lib/dagger/worker/snapshots/snapshots/170/fs:/var/lib/dagger/worker/snapshots/snapshots/169/fs:/var/lib/dagger/worker/snapshots/snapshots/168/fs:/var/lib/dagger/worker/snapshots/snapshots/167/fs:/var/lib/dagger/w
  orker/snapshots/snapshots/166/fs:/var/lib/dagger/worker/snapshots/snapshots/163/fs:/var/lib/dagger/worker/snapshots/snapshots/161/fs:/var/lib/dagger/worker/snapshots/snapshots/159/fs,volatile,index=off,redirect_dir=off", err: invalid argument

Solution is just to kill the dagger container and it goes away.

I imagine this has something to do with the container being killed whilst its doing something when my computer shuts down perhaps??

These aren't deal breakers but just flagging them for you guys

[elfin frigate]

i hit that one earlier today too - saw there's a thread that mentions it, not sure if a fix has been merged (cc @pseudo stream)

previous thread: https://discordapp.com/channels/707636530424053791/1458961181900537988/1459052945965449340

[mild coral]

Yes thats me who started that one 😉

The issue was that even a restart of the container didn't fix it. This is no longer the case. Restart the container its all good

Just wanted to flag that this does still come up however and maybe you guys wanted to do something about it 3

[pseudo stream]

huh okay, must be another cleanup case not getting handled... glad it's at least repairable now. Will take a look to see if we can get a fix for next release!

[mild coral]

for reference this happens only when I restart my computer... docker desktop keeps the original container alive with its volume

[pseudo stream]

Yeah that's a super helpful detail, thanks, probably explains why I haven't seen this particular one myself yet since I rarely reboot

[mild coral]

People judge me for my daily reboot

but I feel like it makes everything run better

[pseudo stream]

failed to sync

[pseudo stream]

i hit that one earlier today too - saw

[warm wagon]

How do people handle Go CGO cross compiling binaries with Dagger for MacOS? Dagger is a dream for cross compiling to other linux OSes / arches everything except for cross compiling to Mac (curse you Apple!!)

[mild coral]

🐳 SSH support for dockerfiles

[pine crag]

Hey @sharp marsh, trying to revive the conversation we were having, based on the discussion I see here, does it make sense to collaborate on this feature? We can take care of the development but would like to confirm if you folks could support us and if this is a use case you'd be interested in co-marketing?

[sharp marsh]

Hey Arsh! thx for reaching out.

We haven't had any new users coming to our community asking for a Dagger and mirrord integration so far. On top of that, it's not clear to me what type of integration will be needed. I don't see any movement in the issue on your repo or any new comments from the OP here. With all this, I don't think there's enough input to understand how to proceed here

[fossil pine]

Finally fixed rustup on my machine. Installed the Dang extension (and probably kept my sanity).

[fossil pine]

@elfin frigate I'm trying to understand if this is working as expected:

"""Rust programming language module."""
type Rust {
  """Source directory."""
  pub source: Directory! @defaultPath(path:"/")

  pub version: String! = "1.90"

  pub ctr: Container! = container().from("rust:" + version)

  """
  Initialize a new Rust module.
  """
  pub new(): Rust! {
    Rust(source)
  }
}

If I set version to private (let), it's set to the dagger version.

Is that how it's supposed to work?

I don't like leaving fields public that aren't supposed to be.

[warm temple]

Sounds like its probably colliding with dag.version

[fossil pine]

Yeah, I guess so. The question is if this is the expected behavior, because that's not clear to me.

[elfin frigate]

definitely not expected, would you mind opening an issue on https://github.com/vito/dang?

[mild coral]

Raised an issue for codegen being non-deterministic for Go with a repo to reproduce the issue ( I think ):
https://github.com/dagger/dagger/issues/11802

[fossil pine]

Here it is: https://github.com/vito/dang/issues/17

What I'd really like though:

• being able to declare a field as private
• but being able to pass it as a constructor param

In other words: I want to be able to initialize it, but I don't want to see it in the dagger output.

In Go, this is possible with the // +private pragma.

[fossil pine]

Basically:

FUNCTIONS
  ctr           -
  new           Initialize a new Rust module.
  source        Source directory.
  version       -

ARGUMENTS
      --ctr Container
      --source Directory
                           Source directory.

      --version string

I want it to be an argument, but I don't want to see it in functions.

[elfin frigate]

fixed this, and https://github.com/vito/dang/issues/15 too - thanks for the reports!

Basically:

[chrome moss]

Hey folks, can someone help me out with getting stuff on daggerverse? Ive got 2 modules. https://daggerverse.dev/mod/github.com/act3-ai/dagger/data-tool and https://daggerverse.dev/mod/github.com/act3-ai/dagger/shields I cant get to show up there. I've tried manually on the site, through the cli, and making a function call and none of them are working.

[cursive bridge]

Sorry it took so long, but here's the issue:
https://github.com/dagger/dagger/issues/11805

[elfin frigate]

weird, i just tried publishing the first one and it worked

[chrome moss]

Which method did you use? Every time I tried it would get stuck spinning or updating

[elfin frigate]

publish button on daggerverse - maybe there was an infra issue? didn't take long either

i left the second one alone if you want to try it again

[chrome moss]

wow yep it worked. Ok then not sure what was going on, but thanks for your help nonetheless

[winter linden]

dagger generate is merged! Should drop in 0.19.11 (imminent). Same idea as dagger check, but for functions that return a changeset to apply to your repo. Annotate your function with @generate / +generate

[winter linden]

Aaaand 0.19.11 is out 🙂

[mild coral]

Very nice!

[winter linden]

RELEASED: Dagger 0.19.11

Faster module loading in large repos

Module loading was appending a **/* include pattern that caused the file walker to traverse the entire repo tree, even when the module itself was small. Removing this brings load times down from potentially minutes to a few seconds on empty cache and sub-second on warm cache.

Parallel array resolution

DagQL now resolves array results in parallel instead of sequentially, so any API call that retrieves a list of objects then makes further function calls aganst each object (function chaining + fan-out) will be much faster.

AWS Secrets Manager & Parameter Store

You can now pull secrets directly from AWS Secrets Manager and SSM Parameter Store as a built-in secret provider — no wrapper scripts needed. Just reference your AWS secrets and Dagger handles the rest using your ambient AWS credentials.

Exit codes >127

Previously, containers killed by signals (exit codes >127, e.g. 137 for OOM-kill) couldn't be captured when using ReturnType ANY or FAILURE. Now those exit codes are properly surfaced instead of being treated as engine-level errors.

Modules on git servers with non-default SSH ports

Dagger module refs pointing to Git repos over SSH now correctly handle non-standard ports (e.g. ssh://git@myhost:2222/repo), which previously failed to parse.

Go generated clients get their own go.mod

dagger generate for Go clients now creates a self-contained go.mod inside the generated directory, pinned to the engine version. This avoids polluting or conflicting with your project's root go.mod.

Bug fixes

• Fixed cache mounts becoming permanently unmountable after an engine restart
• Fixed a catch-22 where a full disk prevented opening the client telemetry DB, which in turn blocked the cleanup that would free space
• Fixed mirror sync accidentally deleting gitignored paths when multiple clients shared the same mirror cache
• Fixed an ARM init crash caused by a wazero bug (bumped to patched version)

[cunning jolt]

Can a function be both check and generate? For example, unit tests are a check but also generate coverage artifacts.

[winter linden]

Yes they can, but producing coverage artifacts is not the way to do that. For example you won't get the report file if the tests fail.

Proper support of test report artifacts is also on our radar. We plan on extending the check interface, to allow returning a custom report artifact instead of just an error. That will be a better way to solve your coverage artifact problem.

[cunning jolt]

I may be missing the point of generate then 🙂 To generate an artifact, you need other steps to complete (compile, UT, static code checks etc.). Is there some way to chain and share step results and/or artifacts when a generate function is run? Maybe I'm getting too far ahead and talking about future state. Is that all wired up in the concept of "Workspace"?

To ask it in another way: What's the difference between +generate and a vanilla function returning a Changeset?

[winter linden]

dagger generate is for generating source-controlled content:

• client bindings
• server stubs
• api docs
• changelog (with a tool like changie)

Typically you call it standalone, manually.

[cunning jolt]

Ah! that wasn't clear to me 🙂 Producing repository managed artifacts (jar, docker image, tar.gz) felt like "generating" too. Probably a language thing for me.

[winter linden]

Yeah those pesky words

We're going with the same definition as eg. go generate

[warm temple]

also a lint --fix would be a generator 🙂

[winter linden]

Ah yes, it fits the definition. I've been wondering if we need a distinct dagger fix for that? But it would be more to avoid surprising users

Actually pretty cool to have formatters built in

[warm temple]

built in formatters would be a big deal for agents

[winter linden]

(one argument against putting formatters/fixers in generate, is that you probably need a guarantee that it runs after all generate functions). If it's in parallel, you can't fix the generated code

We could also upgrade check with support for returning Changesets. If a check returns a changeset, it means it can fix the issue. Then we could dagger check --fix

[warm temple]

sounds tricky but i like the direction

[winter linden]

either that or +fix

[formal kernel]

Hey all!
Is the project active? I see that it hasn' t been updated for 4-5months.

[loud briar]

https://github.com/dagger/dagger/releases 😉

[formal kernel]

Silly me, I was looking at the sub-project https://github.com/dagger/container-use 😅
Thank you!

[winter linden]

Ah, container-use has been in maintenance mode, but there's a new maintainer in town 🙂 so things should start moving again soon! See #container-use

[formal kernel]

Glad to hear! 🙂
Just to make sure - the tool should work or there's something that we should keep in mind?
Basically trying to understand if what maintenance mode and if there's a problematic reason (security/performance) for it (sorry in advance if it's something known).

BTW, while finding the tool accidently online I stumbled upon your video (at some AWS conference) and was one of the first things I saw about the project - it was great!

[winter linden]

no particular security or performance issue with container-use, it's just our engineering priorities: the 2 engineers who did the most work on container-use have since left and are no longer involved at all. The rest of the Dagger team is 100% focused on Dagger itself, and it's already a massive effort.

That's why we've fallen behind on maintaining CU, and are so thankful to power users like @white zephyr for volunteering to take over maintenance of CU.

[white zephyr]

I've been testing container-use since yesterday, and I have some good ideas on next steps. PRs welcome, and if you find an edge case you want to take a look at, let the rest of the community in #container-use know.

[scarlet cloak]

In the main chat, my bot says it’s using Opus 4-5. In the cli status command it returns 4-6.

Has anyone else seen this behavior?

[fossil pine]

not sure about others, but I generally exclude generated code from linters. It's generated, not for use consumption. Many linters ignore generated code by default anyway.

[fossil pine]

I have a large monorepo with a lot of educational content I'd like to migrate to Dagger. Right now I'm using shell scripts, just and a bunch of other tools and it's becoming hard to maintain. (I mentioned this project here before)

So far I avoided migrating to Dagger, because I haven't find a good way to manage an unbound amount of modules, with some abstraction, but with the potential to customize some parts.

With dang and blueprints being added, I've been considering a Dagger migration again.

A couple things I'm not sure how I will solve yet:

Most content have to go through the exact same pipeline...with the exception of building container images, that may be different for each piece of content. So a blueprint would almost be perfect here, except I'd need a way to customize part of a build process.

For example: dagger call publish runs all common pipeline steps, runs all container image builds and publishes them to the right registry.

Right now, I don't see a way how I could reuse a blueprint for this purpose.

I also considered not using blueprints at all and instead of a separate module per content I could create a single module at the repo root (all content is in a single repo).

However, I would probably run into the exact same issue: I'd have to customize the build process for a whole lot of content (either with one giant switch or something else).

I can't seem to find a good approach.

I only mentioned container image builds as an example, but basically I have the same issue with tests which would also be content specific.

Any ideas?

[winter linden]

What are the differences between container images?

[fossil pine]

They are completely different. 🙂

For different tutorials

[fossil pine]

And in some cases there are multiple containers built in a pipeline

[winter linden]

But other than the contents of each container, everything else in the stack and delivery pipeline is the same?

[fossil pine]

Other than the container images and how they are tested, yes.

[patent slate]

I have a large monorepo with a lot of

[plush patrol]

Am I able to pass args from terminal to dagger shell?
Perhaps something like dagger -c 'container --platform=$1' -- linux/amd64.

[sand sierra]

Can the directory.DockerBuild be used with a form of --no-cache?

[cerulean token]

have you tried something akin to passing the current timestamp as a build arg? this should avoid cache hits

[stoic knot]

Why is it that a v0.19 client (dagger-cli) cannot talk to a v0.18 server?

If I have LTS branches, and my developers get new tooling, but the branch they are on expects old tooling (including bring up an old engine for the SDK), it still fails. Is it expected I keep multiple versions of the CLI around in this situation?

[sand sierra]

have you tried something akin to passing

[jagged flicker]

We don't have LTS branches for now. And we are currently focused on adding a lot new things to new versions, more than maintenance of older versions.
That said, a module that declares an engine version (for instance a v0.18.x) should work perfectly fine even after to upgrade the server to a v0.19.x. So you should be able to upgrade anyway.

the branch they are on expects old tooling (including bring up an old engine for the SDK)
What are the issues preventing to upgrade to a newer engine?

[stoic knot]

yeah, it's that module support that has me wondering why the cli & engine cannot play nice too

we don't use modules, we use the SDK directly

so there are 3 things to upgrade: cli, engine, go.mod

trying to coordintate those 3 with a zero-impact to devs has not born fruit

we've been trying to upgrade from 18 to 19 and it's been a fraught process, I think out third try will be the charm 🤞

context, I'm probably a dagger elder, from the 0.1.x days, helped work on the original CUE interface. I'm an outlier and opinionated :]

The SDK is still the interface that makes the most sense to me, unlocks the most potential

[oak estuary]

Hello everyone,

Got a quick question here. I am bumping my dagger version from 0.18.8 to 0.19.10 and i am having an issue executing a module from my private github repo.

When i try bump the version on the project and use the new engine version i get an error

TypeError: app() takes 0 positional arguments but 2 were given

In /runtime script. I am using python sdk.

If anyone has any insights or some pointers i would appreciate it, thanks

[oak estuary]

This is on loadModule function

[sharp marsh]

👋 just replied in #1030538312508776540.

[ancient ivy]

Hello everyone, you indicate use dagger in kubernetes with ci runners, or use a ci as gitlab or argoworkflows?

[sharp marsh]

hey Lucas, not sure if I follow the question. Are you asking if we support running dagger in gitlab or argo workflows?

[cursive bridge]

I've got a question about dagger's withExec expect option. I'm working with trufflehog, and that program has an option to exit with code 183 if secrets are found. I'm trying to allow trufflehog to exit with 183 without failing dagger by using expect: ANY to withExec. Specifically, this is the line dagger prints:

✘ withExec trufflehog filesystem --json '--exclude-paths=$HOME/trufflehog/.trufflehog-exclusions' --fail --results=verified,unverified,unknown,filtered_unverified '$HOME/trufflehog/scan_directory' (redirectStdout: "report.json", expect: ANY, expand: true) 2.4s ERROR
...
! exit code: 183

However, dagger is failing with that 183 exit code when trufflehog finds secrets. I thought an expect: ANY would mean the program can exit with any error code and dagger won't fail the job. Is that understanding correct?

[jagged flicker]

Are you using the latest v0.19.11 version?
Previously exit codes > 127 were not supported by ReturnType ANY but that should be fixed with this version.
See the release message here #general message

[winter linden]

Unfortunately the recent expansion still prevents from catching exit codes between 129 and 192. That choice of exit code by trufflehog is quite unfortunate.

See explanation: https://github.com/dagger/dagger/issues/11569#issuecomment-3751614913

[cursive bridge]

I'm using 0.19.9, but seems like even the latest won't handle trufflehog. I'll have to figure something else out. Thanks all!

[winter linden]

• The long-term fix is for dagger to no longer rely on buildkit, and to get the actual exit code & signal code directly, so we can expose them cleanly in the API (the flattening is an artifact of a 50-year-old shell interface)

• Short term, you can execute trufflehof with a shell wrapper that replaces exit code 183 with something dagger can catch - eg 193.

#!/bin/sh

trufflehog "$@"
status=$?

case "$status" in
  183)
    # TruffleHog: secrets found
    # Remap outside ambiguous window
    exit 193
    ;;
  *)
    exit "$status"
    ;;
esac

Note, if trufflehog happens to be terminated by signal 55 (128+55 = 183), then your wrapper will incorrectly assume it exited with code 183, and that result will be incorrectly cached by Dagger. This is the edge case we're trying to avoid in the first place. BUT, in your particular case it is very unlikely to happen. So it's safe for you to use this wrapper, even though it's not safe for Dagger to do this all the time for every workflow.

I hope this helps!

[cursive bridge]

It does! I hadn't thought about trying to map the exit code to something else. Neat idea!

[chrome moss]

question on dagger generate. If I have 3 generate functions, A, B, and C. But A and B depend on C's output, how is that evaluated? If I have A and B call C use its output, is the dag of C evaluated twice, or is it de-duplicated? I am wondering a best practice approach here

[winter linden]

It will call them all in parallel.

• If they call each other via the dagger engine (dag.foo()) then all calls will be cached / de-duplicated.
• If they call each other via native function calls within the module codebase (go, typescript, python...) then the call itself is not de-duped (dagger doesn't know about it) - but their subsequent system API calls will be de-duped.

Either way, dagger makes no attempt to detect dependencies between them ahead of time, to change the evaluation order

[chrome moss]

thanks for this!

[loud briar]

@winter linden Did --envfile ever make it live?

Apparently not

[ancient ivy]

So sorry, the question is that is possible use dagger with out gitlab or other ci, just using the engine on kubernetes, and which strategy is better

[ancient ivy]

Have the plan to go sdk Accept generic types as interface{} or any?

[sharp marsh]

at the moment you need some external orchestrator (github actions, gitlab ci, tekton, jenkins, etc) to manage your dagger pipelines. Your dagger engines can be hosted by these orchestrator or self-hosted in a k8s cluster as you mentioned.

Having said that, we are in the testing phases of a Dagger native CI product where all the orchestration and infrastructure will be handled by us to provide the best possible experience. Additionally, from the compute side, our machines are faster and cheaper to the ones that you can get today in all major vendors. If you're interested and you're ok with being an early customer, let us know and we can chat further!

[sharp marsh]

not for the moment. What are you trying to achieve? Maybe interfaces might help here? https://docs.dagger.io/extending/interfaces/

[cursive bridge]

Would this orchestrator have a self-hosted/on-prem option?

[winter linden]

not at the moment. We know everyone got used to self-hosting CI. Sometimes for pure compliance, but often for cost & performance. We think self-hosting for cost & perf only makes sense because current CI platforms are "dumb" - they don't understand what they're running, so they can't be meaningfully faster or leaner than commodity compute.

However we plan on changing that 😁 Our goal is to make Dagger Cloud much faster and leaner than legacy CI, by tightly integrating the whole stack: triggers, compute, cache, scheduler, telemetry, execution engine. To do that we need full control of the stack. But we think the result will justify not self-hosting, at least for performance & cost.

[cursive bridge]

I think a self-hosted option would open up additional customers. There are many reasons why a company would not be able/willing to take a cloud option. Off the top of my head:

1. Security/data concerns
2. Need to support air-gapped or other limited network access options

I don't know the size of that market, but I know it exists. I know financial institutions, for example, tend to be very reluctant to use any cloud based services for a variety of reasons (one being concern about regulation compliance I'd bet).

[winter linden]

Yes that market very much does exist. And we know we will lose customers in the beginning with this approach. But, sometimes you need to focus... And in my experience, while everybody always asks for self-hosting, not everyone really needs it for compliance reasons. And among those who do, many are open to alternative scenarios, for example: a secure tunnel for external CI to access on-prem services. This is a scenario we already encountered and plan to support.

And, eventually, we will expand our support; first, to single-tenant managed deployments; then eventually to actual self-hosting. But not right now.

This is a tradeoff. In return for losing some early opportunities, we can focus on making a product that is 10x better than the alternative, which has many benefits of its own 🙂 Better to build a 10x better product for a slice of the market, than an average product everyone can use (but will they, if it's just average?)

[cursive bridge]

Makes sense for sure. Unfortunately we won't be able to consider it until there is a self-hosted option because of regulations and network access limitations. We're small fry though (startup). We're in a phase of rethinking things to support different deployment environments so I was interested in wether a dagger CI could be a solution for us, but as I said unfortunately it'd have to be self-hosted in order to support some of our deployment models (air-gapped). It'd also need to be something deployable (ie we can update a remote instance via a bundle/artifact that would include binaries + config).

I'm eager to see what dagger CI will look like though, nonetheless.

[cunning jolt]

We are in the same boat 🙂 But as long as Dagger supports local first and current CI orchestrator supported self-hosting scenarios (running it in Kubernetes) we can still use it.

[winter linden]

Regulations I can't help you with... (unless it's about hosting on EU, which we support :-P)

Network access, you can often address with a secure tunnel. Often the on-prem dependencies don't have heavy bandwidth or latency constraints, so it boils down to secure transport. This is a common scenario for several testers.

[winter linden]

Yeah we will continue to support this of course. Dagger Cloud will just gradually leave your setup in the dust in terms of speed, scale and efficiency. But that's the price to pay for excessive controls 🙂

[cunning jolt]

I wouldn't call them all excessive. There are good reasons for those controls to exist. It's mainly to stay out of the news! Also, speed is only a single dimension. There are many other reasons big companies stick with existing CI solutions. I sincerely hope you will be able to change/revolutionize that landscape! 🙂

[winter linden]

I was just teasing you with the "excessive" part 😛 The restrictions are what they are. We would love for Dagger Cloud to be usable in every CI deployment, even the most locked down. Eventually we will get there - just gradually.

[dusty knoll]

Hi, no announcements since 10/2025 what's happening ?

[winter linden]

We've been focusing on incremental improvements and supporting our community here. Since 0.19 in October we've shipped 11 incremental releases with tons of improvements 😁 just haven't blogged about it. But we should ship 0.20 and write down every we shipped.

Also we're working on the next major iteration of Dagger Cloud - as a complete CI platform. In private testing now, will make a big announcement when it's ready.

@dusty knoll what version are you on currently?

[dusty knoll]

v19.6

Just that i love read blog maybe 😅

[pulsar garnet]

Hi, does dagger use DinD - docker in docker?

[winter linden]

No, Dagger does not have a runtime dependency on docker. It bundles its own container runtime and calls the underlying linux kernel directly to orchestrate containers.

If you share more details about your use case, I can give you a more specific answer.

[pulsar garnet]

my concern was performance issue on CI/CD Github Actions particularly, as DinD can bring performance overhead. And specially about default github runners.

[pulsar garnet]

Also we can't use DinD in any case in company

[patent slate]

The fact you are spamming this in this Discord server would be grounds for me not hiring you from the start.

[mild coral]

🧑‍💻 Developer experience with checked in dagger codegen

checking in the codegen on mono repos.

[mild coral]

Just wondering it would be possible to customise the name of the github status check that is created by dagger cloud? The use case is that we want to uae github rulesets to enforce our pr checks, however when passing function parameters, they appear in the github status check name, modifying it from what was expected. Therefore we cant apply rulesets

[winter linden]

We're converging towards dagger check being the recommended source of github checks (each dagger check maps to a github check). See a PR on our repo for what that looks like. There are no arguments in the name (since dagger checks do not accept arguments by design)

[warm wagon]

Is there a good recommended workflow for developing daggerverse modules?

I.e., I have a few modules I want to hoist up to my daggerverse org wide repo and want to locally check it works before commiting. But doing a dagger install ~/daggerverse/my/module is abit clunky ... I suppose unless I validate it locally and then do another dagger install github.com... to right the remote module?

[mild coral]

Would it be possible to use that without using dagger native CI? Just an FYI we arent using the dagger github action right now, perhaps it is supported by this?

[winter linden]

Would it be possible to use that without using dagger native CI?

Good question. wdyt @sharp marsh @rigid pebble @elfin frigate ?

we arent using the dagger github action right now, perhaps it is supported by this?

I don't think that makes a difference, Dagger Cloud doesn't care whether the client is using the GHA action or not.

[sharp marsh]

Good question. wdyt @sharp marsh @matipan @elfin frigate ?

My first impression is that this is one of those features that it's difficult to provide a good UX if we don't own the whole stack. Running dagger checks within GHA or any other CI/compute provider will make some features like re-runs and cancellations quite challenging. At the same time having a clean history of events to keep track of repo healthiness and test flakiness also becomes difficult.

My initial take would be to improve the current trace view to make it a bit more "check" aware and leave the current Checks page for Native-CI users.

[winter linden]

To be clear Chris isn't talking about the "checks" page in Dagger Cloud, but about github checks added by Dagger Cloud in the PR

Right now there are 2 different ways Dagger Cloud does that:

• From regular traces (with self-hosted engines)
• From checks (with dagger-native CI)

Chris is asking if in the future they could get the second, from running dagger check on self-hosted engines

[sharp marsh]

Gotcha. Makes sense since navigating the trace to see which trace failed is not the best UX, I agree.

[mild coral]

Yup thats what I am wondering 🙂

[jagged vault]

Hi, has the Dagger addon for VSCode any trouble to update with current index funcs ?
Still remains on funcs from first tutorial poc 🙂

Thanks

[tired moth]

then why we are not having live development support? just curious to know

[tired moth]

from which version this went live? any docs mentioning?

[sharp marsh]

this has always been the case @tired moth

[warm wagon]

Curious: is there a recommendation for setting "llm friendly" output? I.e., if an agent runs dagger check it definitely shoves alot of tokens into the window with the dots and spinners since I think it's using the tty mode. dagger check --progress plain is better line by line but not sure if there was more that could preserve tokens but still have the breadth of information. Obviously there's --silent which is more binary.

[sharp marsh]

dagger check --progress dots generally has a good balance. cc @elfin frigate in case you've been using something different

[elfin frigate]

i've been using dots. there's a new even quieter one, logs, but it's not shipped yet. there's also report which will be quiet and then print a final report. dots is basically logs + report + streaming dots to indicate activity

[warm wagon]

Y’all’s keep teasing me with these features! 😂 can’t wait!

[loud briar]

👀 I am here for this. We're using dots because plain is awful on Gitlab CI job logs, but that sounds great

[winter linden]

I've been using a skill for this. I think we should consider making an official skill...

If only to tell the llm to use background execution and check progress async. Also bundles a shell script that picks the right progress flag

[tired moth]

If i have raspberry pi 5 8 GB and i have installed their officially supported ubuntu 24.10 then i dont need to install docker or containered or nerdctl anything and by installing dagger only i can work with dagger? is it right?

[tired moth]

@winter linden @sharp marsh can anyone confirm this please?

[tired moth]

as mentioned in this docs we need to give any one container runtime https://docs.dagger.io/reference/container-runtimes/

are we going to add support for lxc?

[sharp marsh]

@tired moth we don't have instructions to run Dagger without a container-runtime currently because it's not convenient. The engine bundles different components like dnmasq, runc and CNI binaries amongst other things which running as a container helps with the DX. If you're really interested in making it work without our recommended container runtimes, you can always give it a shot to make it work with something like systemd-nspawn or some other OCI runtime

[sharp marsh]

not for the moment. We haven't had demand for it

so going back to my previous comment, there's no strict dependency between Dagger and docker or any other container runtime. It's just that packaging and running it as an OCI artifact is currently the most practical way to distribute it

[tired moth]

ok thanks for clarifying

[sharp marsh]

@mild coral this will go out in the next deployment in around 30m from now.

[mild coral]

Oh wow sick!

Thanks very much 🙂

[torpid maple]

Why are secrets on full display in Dagger cloud when the argument was annotated with Annotated[dagger.Secret, Doc("Container registry secret")]?

@object_type
class Swup:
    @function
    async def publish(
        self,
        source: Annotated[
            dagger.Directory, DefaultPath("app"), Doc("hello-dagger source directory")
        ],
        image: str,
        registry_address: str | None,
        registry_username: str | None,
        registry_secret: Annotated[dagger.Secret, Doc("Container registry secret")] | None
    ) -> str:
        """Publish the application container after building and testing it on-the-fly"""
        await self.test(source)
        container = self.build(source)
        
        if registry_address and registry_username and registry_secret:
            container = container.with_registry_auth(
                address=registry_address,
                username=registry_username,
                secret=registry_secret
            )
        
        return await container.publish(image)

Also I'm using _EXPERIMENTAL_DAGGER_CACHE_CONFIG: type=registry,mode=max,ref=${CI_REGISTRY_IMAGE}/dagger/cache:latest.

How would I ensure that dagger engine is authenticated to access that registry?

[warm temple]

Is it possible you're passing the actual secret value as the argument rather than a reference to an environment variable, file, or command?

[warm wagon]

I've gotten this nasty error trying to run some checks on mac runners in GitHub CI:

start engine: driver for scheme "image" was not available

I realize this is because the GitHub mac runners don't have a container runtime - very unfortunate: any tips / tricks? I see this GitHub action that will setup Docker on the runner but not sure if there's a better way

https://github.com/douglascamata/setup-docker-macos-action

[torpid maple]

You mean using --registry-secret $CI_REGISTRY_PASSWORD instead of --registry-secret env://CI_REGISTRY_PASSWORD?

[warm temple]

Right, it should be --registry-secret env://CI_REGISTRY_PASSWORD

[torpid maple]

To pass host environment variables as arguments when invoking a Dagger Function, use the standard shell convention of $ENV_VAR_NAME. 🤷
https://docs.dagger.io/extending/arguments/#string-arguments

I guess I didn't read far enough, my bad.
https://docs.dagger.io/extending/arguments/#host-secret-providers

[warm temple]

no worries, we should make this more obvious 🙏

[winter linden]

With the upcoming workspace config it will be easier for us to catch this and warn the user, since the string $FOO will be in our config file (whereas today it's expanded by the user's shell, out of our reach)

[steel bridge]

I'd definitely be interested in giving that a try

[mild coral]

Hey Marcosnils

I am trying to use this but not seeing my checks listed as individual github checks:

Just wondering if there is anything I need to enable?

My github action step looks like this:

- name: Call Dagger Function
        run: |
          rm .env
          mv .env-ci .env

          exec dagger check
        env:
          BAO_ADDR: ${{ vars.BAO_ADDR }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

[sharp marsh]

hey Chris! what's your Dagger Cloud org name? The feature went out behind a feature flag so we're sure it works as intended before enabling it to everyone

[mild coral]

nine

Yep all good!

[sharp marsh]

let me enable that for you really quick 🙏

[mild coral]

Thanks I'll give it a retest in an hour. Jumping out for a bit 🙂

[sharp marsh]

np. Should be enabled in a bit

[sharp marsh]

should be good now Chris 👐

[mild coral]

Looks good Marconsils!

Will keep testing it and let you know how it goes

One thing I did notice just now is that the checkCodegen check shows as success on the github side but it has actually failed

The other thing I was going to ask, is there a way to control the maximum checks that run in parallel?

[sharp marsh]

sweet. I'll 👀 tomorrow

[torpid maple]

What's the best way to implement Dagger caching in the context of a GitLab CI pipeline.

Currently I'm using.

_EXPERIMENTAL_DAGGER_CACHE_CONFIG: type=registry,mode=max,ref=${CI_REGISTRY_IMAGE}/dagger/cache:latest

But I get the impression this isn't caching all the things, such as cache volumes etc.

Should I just give up and have a persistent runner host, or cache /var/lib/docker between runs?

I don't care how hacky the solution is, I just need my Dagger pipeline to be faster than it is currently.

[loud briar]

I tried this ages ago. It wasn't worth the time spent on it, you need a persistent Dagger engine with a large nvme drive

[torpid maple]

Shame.

[loud briar]

It's worth it. Didn't take long to write a terraform module that produces an engine accessible to my runners and any issues with caching vanished

[torpid maple]

Regarding the persistent engine, I see the container has a volume called /var/lib/dagger if I can persist that I would essentially be golden no?

[loud briar]

I tried it, the cache upload/download times were not pretty and the performance wasn't as good as local. You should try it though, I gave up on it pretty quickly in favour of a persistent engine

[sharp marsh]

this should be fixed Chris! LMK in case it's still not reflecting the correct status for you

[warm wagon]

Is there any advice for working with huge files? I'm talking 10gb. My pipelines break down pretty quickly in filesync

[carmine seal]

You may want to include the repo/project name, and maybe workflow/job name. Chances are you're calling different functions, each run will override the previous unrelated image

[torpid maple]

I figured it's be smart enough to cache any and all things in that cache image no?

Essentially like what would happen if using a registry cache during a targetted multi-stage build, where not necessarily all targets/stages would be built in a given run?

[chrome moss]

Am I correct on the assumption to never use dag.Secret().Plaintext() inside a function call since that might potentially expose it in logs/cache?

[elfin frigate]

calling .plaintext should be fine - just don't accidentally log it yourself, but even that has a safety net where secrets are scrubbed from output. and don't set value as a plaintext env var or arg in a Container - use withSecretVariable instead

[chrome moss]

hmm, ok so building in code should be fine? For some context here, UV is pretty annoying when it comes to credential handling. We are trying to help the team by saying you give us your secrets (tokens) and I build a netrc file that is eventually passed as .netrc to the uv build container via .WithMountedSecret("/root/netrc", netcrc). I got stuck because I thought anyway I try to do that from the point I take a dagger.Secret starts exposing it.

EDIT: I basically want to make sure this daggerverse module is kosher because its basically doing the same thing I would: https://github.com/purpleclay/daggerverse/blob/3893340aa32e2140d6181124740f0a0a23e59588/netrc/main.go

[elfin frigate]

not 100% sure i follow, jumping to the nearest tricky idea in case it's right: if your problem is that you're given (token1, token2, token3) as Secret and need to turn those into a single Secret that gets mounted as a file, that should be safe as .plaintext, .plaintext, .plaintext => setSecret("foo", plaintext1+plaintext2+plaintext3) (in .envrc format) => withMountedSecret

[elfin frigate]

that particular module doesn't seem kosher - this part would be better off storing the Secret objects themselves, rather than storing their plaintext values, which will indeed end up in the cache: https://github.com/purpleclay/daggerverse/blob/3893340aa32e2140d6181124740f0a0a23e59588/netrc/main.go#L125-L131

[chrome moss]

Yep this is the answer I was looking for. Perfect. Thank you for this!

[chrome moss]

I'm glad my spidey senses worked for once on that module

[winter linden]

🇫🇷 French-speaker daggernauts: our friends at Zenika just released a podcast on Dagger, featuring @vital cape and @rancid spire to share their experience running Dagger at large scale in production. https://www.youtube.com/watch?v=aBpfFwZqyHc

[mild coral]

Hey team. I am noticing that when using toolchains and calling a toolchain function, the main module and all of its dependencies are loaded as well.

For example if I have the following dagger.json...

{
  "name": "main",
  "engineVersion": "v0.19.11",
  "sdk": {
    "source": "go"
  },
  "toolchains": [
    {
      "name": "ci-tools",
      "source": "infrastructure/dagger/ci-tools"
    }
  ],
  "dependencies": [... heaps of dependnecies]

...and I call dagger call ci-tools lint, I notice that the trace will first load the main module including all its dependencies, before finally loading ci-tools.

I was wondering if it were possible to optimise this so that only the toolchain module in question is loaded?

The reason why I am raising this is that we have a mono repo where all modules are basically a dependency of the main module. We have 60 modules now and if I want to lint one of them, we pay for all 60 to be loaded as part running that one function. On a cold start this can contribute to an extra 30s of waiting time. When cached, the difference is about 5s.

Its not a big one, but just wondering if there were any plans to optimise this 🙂

[winter linden]

I think this can be optimized with the upcoming #1468070450524459029 which completely changes how toolchains work internally (effectively merging the "toolchain" concept into modules)

[cunning jolt]

I reported this same thing here too - #daggernauts message. I'm hoping modules v2 fixes it

[mild coral]

Something interesting that would be good to address - not sure if its a modules v2 thing or not... is often I find the codegen changes due to the presence of a .env file. This is fine if the same .env file is used everywhere, however in cases where the .env is not (for example in CI we delete the .env file prior to execution) we are finding that the codegen changes and in some cases the go code fails to compile.

In the above example with that dagger.json I posted, the ci-tools accepts the SSH socket as a parameter ssh *dagger.Socket. However due to the presence of a .env file that happens to supply this parameter, the parameter turns up as an optional parameter when calling the module from any other module. The problem with that is, we don't use the .env file in CI so the codegen causes this to turn up as a required parameter in CI. Therefore the code doesn't compile

The solution would be to delete the .env file before running dagger develop locally and making it all compile in this state. However this breaks the local experience.

Not sure what the best way to addresss this is

[winter linden]

User defaults interfere with codegen

[vast mica]

when daggerclaw?

wen*

[wraith sonnet]

Hi @winter linden

I’m excited to see the next evolution of your new feature (aka module v2).
I’ve read your papers on Workspace and Artifact, but I still don’t fully understand whether it will be possible to share files between a Workspace/Artifact and the host filesystem.

For example, imagine running nested modules through a CI/SCM engine like GitHub or GitLab: a main CI module triggers another module, such as a testing module that generates a report file. The CI/SCM engine can annotate or decorate the merge request only if it has access to that test report. However, since the report is produced inside the testing module, I’m not sure whether the main CI module—and therefore the CI/SCM system—would be able to retrieve it.

Will this type of file sharing be supported ?

[jagged flicker]

A module's function can return a changeset, and by doing so the generated files can be easily exported on the host. That way the CI system should be able to access it.
IIRC we discussed an evolution of check functions so they can not only indicate if the check passes but also returns assets (through a changeset I guess) for this kind of use case, when a check function (running tests is one of the main puprose, but also valuable for scanners for instance) wants to return files, reports, etc at the same time. It's not yet done, but that's on the ideas to implement.
All that should work with the current way and with the new workspace/module structure.

[wraith sonnet]

Thank you @jagged flicker for your answer.

I’ll test the Changeset type asap. It might solve my issue, but I’m wondering about cases where you have many nested modules. In that situation, every module would need to expose a function returning a Changeset, which could become quite time consuming to maintain.

When I first heard about Workspace, I assumed you would provide a shared filesystem space, making it easy for modules to exchange files and therefore fully cover my use case.

Maybe I misunderstood and this scenario is already supported ?

[winter linden]

Use case for workspaces?

[warm wagon]

Is there a way to set a deterministic dagger check that only runs when certain conditions are met? I want tobuild GitHub focused checks like "does PR have right format" or "does PR have labels" - should be pretty easy with gh but doesn't make sense as a normal check - I suppose, as I talk it out, it makes more sense as a GitHub action

I just really hate github actions and want to move as much off of it as possible and onto your platform 😂

[winter linden]

We are working on diff-aware check filtering. Will be available in CLI but also in Dagger Cloud

[warm wagon]

https://tenor.com/e4bv2c2FQYv.gif

[winter linden]

The primary use case will be optimization - simply skipping checks that are not invalidated by a given diff.

But, perhaps we can extend it to checks that operate on the diff itself (like, is it formatted correctly etc) --> but no guarantees. It might be true that it's actually a proper use of Github Actions? TBD

If it's fundamentally about Github-specific concepts, like pull requests, labels - it might actually not be CI, but Github workflow customization (there is a difference 🙂

[warm wagon]

Yeah fair. Usually GitHub things are where GHA shines - sort of also invalidates the ethos of "run it anywhere" if a PR check is meant to ... check a PR on GitHub

[winter linden]

Sometimes the implementation is tied to Github-native concepts, but there is an underlying fundamental concept that deserves to be freed with a portable API 🙂 But distilling that takes time

[raven stag]

@pseudo stream , https://github.com/dagger/dagger/pull/11830 thanks!!! (individual gc settings in engine prune). This is great for us!
I have a question surrounding this to understand the impact.. 😇
Is there any logic on the entries being pruned in the cache when the GC is going through the list of entries, in respect of the longevity of the entries? (e.g. If we configure 200gb to be left in the cache, are those random? the newest entries? the oldest entries?) - Is this based on purely the buildkit GC i suppose, anywhere you can point me to finding this would be too

[tired moth]

is there any reference implementation of dagger running on https://docs.github.com/en/actions/concepts/runners/actions-runner-controller ?

[sharp marsh]

records to be pruned are sorted by a combined score of lastUsedAt (oldest first) and usageCount (least used first) via sortDeleteRecords (https://github.com/dagger/dagger/blob/6a980035cef21720319ed10f5b7d45f451b554ec/internal/buildkit/cache/manager.go?plain=1#L1209). This is an LRU/LFU combination. The normalized index of recency and frequency are summed, so the least-recently and least-frequently used entries get deleted first.

[raven stag]

This is perfect, wasn't expecting this 😛 Thanks @sharp marsh

[sharp marsh]

@tired moth have you seen https://docs.dagger.io/reference/deployment/kubernetes ?e

[tired moth]

Yes and just wanted to confirm that each node in k8 clister will get its own dagar engine also while it's running job from github action?

[sharp marsh]

yes, that's usually how we've seen users adopting dagger with ARC in k8s enviroments

[tired moth]

Okay thanks

[jagged vault]

Oh didn't knew @winter linden spoke fluent French, Bravo pour ton excellent Français technique ! 😎
Very nice podcast on Dagger Vs real IT challenges 🚀

[hoary spoke]

Hey everyone!
I’ve been experimenting with a small Gleam SDK for Dagger that generates type-safe, idiomatic bindings from the GraphQL schema and runs pipelines via a CPS-style, deferred execution model to keep data and side effects separate.
The goal is to explore whether Gleam could be a good fit for writing Dagger pipelines in the DevOps/SRE space, and maybe serve as a starting point for a tighter Gleam integration in the future.
Repo (very early stage): https://github.com/avit-io/dagger_gleam
I’d really appreciate any feedback or thoughts on whether this direction makes sense from the Dagger side.

[winter linden]

Hello! I had never heard about Gleam, so will look into it 🙂

Do you plan on supporting modules, or only providing a core client library?

Would your goal be to maintain this as a community SDK, like eg. Rust, PHP etc?

[hoary spoke]

Thanks a lot for taking a look!
My goal is to get a stable core SDK first: a type‑safe client over the GraphQL schema (containers, directories, files, etc.) plus the CPS / deferred execution layer to cleanly separate pipeline description from execution.
Once that foundation feels solid and battle‑tested, I’d really like to move on to Dagger Modules support on top of it.
The intention is to maintain this long‑term as a community SDK, similar in spirit to the Rust / PHP ones: keep it up to date with Dagger, follow feedback from the team and community, and evolve it if there’s interest.

[winter linden]

@here Introducing the Dagger changelog! If you're curious what we've shipped lately, and what we're shipping next... You can now visit https://dagger.io/changelog and find out!

[cunning jolt]

That's the prettiest changelog I've seen 😍

[mild coral]

Love it thanks!

[jagged vault]

Hello, just tried to update dagger engine from v0.19.11 → v0.20.0 as usual, this time it doesn't like something about my workspace (Doc. tutorial with Agent).
Any update, generate, install... command fails the same. 🤔

PS: If I remove the dependencies, the update succeeds.

{
  "name": "hello-dagger",
  "engineVersion": "v0.20.0",
  "sdk": {
    "source": "typescript"
  },
  "dependencies": [
    {
      "name": "cypress",
      "source": "github.com/quartz-technology/daggerverse/cypress@d58a027ddcaf210b6e2c5feba307c3b48fdb0255",
      "pin": "d58a027ddcaf210b6e2c5feba307c3b48fdb0255"
    },
    {
      "name": "proxy",
      "source": "github.com/kpenfound/dagger-modules/proxy@proxy/v0.2.6",
      "pin": "428ffe16f0a2e3c9e4d0d9debf6420db29d3cb64"
    },
    {
      "name": "workspace",
      "source": ".dagger/workspace"
    }
  ],
  "source": ".dagger",
  "disableDefaultFunctionCaching": true
}

[jagged vault]

Maybe seems related to no more supported types from current Doc. tutorial ?

https://docs.dagger.io/getting-started/quickstarts/agent-in-project#create-an-agentic-function

[winter linden]

merged: more reliable Typescript SDK codegen. https://dagger.io/changelog#more-reliable-typescript-sdk-generation

[winter linden]

shipped: if your Dagger Cloud account is authenticated with Google, it's now easier to connect git sources from Github. https://dagger.io/changelog#easier-github-source-setup-for-google-authenticated-teams

shipped: we made our Github Checks integration more reliable. https://dagger.io/changelog#more-reliable-github-checks-integration

[oak estuary]

Hello there guys, got a question. Currently we are using dagger and i was wondering if we can somehow use official dagger engine image with custom pypi mirrors. We are now forking and rebuilding the image each time we want to update dagger engine version

[loud briar]

Have been testing --progress=logs today. Tiny little change but exactly what I wanted - users don't need all the Dagger stuff, they just want the actual content of the exec statements 👏

[cerulean token]

I'm not familiar with how to configure a custom PyPi mirror; what do you change in the dagger engine image to achieve this?

[sharp marsh]

hi there!

would this be customer pypi mirrors for the python modules? do your mirrors require some sort of credentials/auth?

[oak estuary]

Yes that is our internal pypi mirror with auths added, we were adding it under tool.uv.index in sdk/python/pyproject.toml in the dagger repo and then building and publishing an image with toolchain release dagger function,
Are we doing it correctly?

[cursive bridge]

Is there a recommended paradigm for starting a service for testing and waiting for that service to be running before executing tests? I'm working on tests for a sonarqube module, and in order to test I need an actual version of sonar running. I have it working as a service, but the logic I've tried to verify sonar is running seems less than ideal. First I had a loop inside withExec, which ended up printing a lot of nonsense while waiting for sonar to come up. I tried moving it to native Go, but still have a go routine that basically calls into the container via withExec looking at the status endpoint.

It seems like the better way is to try to access to endpoint from the test code and not via curl in the container. Is that possible? Is there a better way to do it?

[sharp marsh]

are you hardcoding the pypi mirror username and password there?

if you set the tool.uv.index in your main module's pyproject.toml AFAIK it should work the same way as setting in the engine's python SDK

[sharp marsh]

here's a thread where Helder describes this behavior #1337422270360191036 message. He's no longer working at dagger but we can help you so it works for your use case

[amber island]

I'm actually working on this at the at the moment, starting with implementing the ability to define docker HEALTHCHECK commands via the dagger api: https://github.com/dagger/dagger/pull/11911

Once merged, I'll be extending our current service bindings to have them execute the HEALTHCHECK command (either defined via the dagger api, or if it came with a docker image you referenced in a From(). Here's an example integration test of what I'm working on: https://github.com/alexcb/dagger/blob/de059438ab783ffe3ad0a3b8472adda87b7e314e/core/integration/services_test.go#L2635-L2641

[cursive bridge]

That looks like a big improvement, although I think what I'm looking for is really a readiness check. Is the health check intended to be continually running, or something that determines a service is ready to accept connections (readiness)?

[tired moth]

Any update on live development support in dagger for local development?

[winter linden]

Here is our changelog: https://dagger.io/changelog

We update it several times per week, so if there's any progress on live dev., it will be there

[tired moth]

haha thanks for sharing but after checking this only i have asked, anyways any hope or update? please share

[warped bobcat]

Hello 👋
if you are in "the west coast"of France 😁, @paper grove organize a Dagger workshop on our Zenika office the March 26th
👉 https://www.meetup.com/fr-fr/nightclazz-by-zenika-nantes/events/313599554

[mighty flax]

I'm actually working on this at the at

[cursive bridge]

Is there a way to disable the dagger version update message that appears at the end of a call? It's useful in some cases, but when running a pipeline of steps for another team it is noise.

[carmine seal]

Is there a way to disable the dagger

[mighty flax]

Hey. Finally took teh time to write this issue https://github.com/dagger/dagger/issues/11954 . let me know if the need is not clear enough. thank you Dagger !

[chrome moss]

Is there any concern from a security perspective with having a "shared" runner for teams? We currently use a dagger engine paired with a gitlab runner in docker/kubernetes that multiple teams would share to run dagger in the CI.

[winter linden]

It depends on your trust boundary. A shared engine will not prevent different users from hacking each other. If you don't trust your team do not hack each other, then you should run them on separate engines (separation at the machine boundary). Most teams use shared engines within the team (tons of performance and efficiency benefits), it works fine. But some teams have more extreme trust models, and can't do that.

[rigid pebble]

⚠️ Our database provider is currently experiencing some downtime ⚠️

This affects telemtry ingestion and querying. You might see failures when sending trace data to Dagger Cloud or while browsing traces. Its not a full downtime and we see that the majority of ingestion and queries are working. We will keep you posted as we work with our provider to resolve the issue

[rigid pebble]

Issue has been resolved! ✅

[chrome moss]

Are things like secrets shared between sessions like cache?

[winter linden]

MERGED: Service API now honors Docker healthchecks, courtesy of @amber island

https://dagger.io/changelog#service-api-honors-docker-healthchecks

MERGED faster git fetches (up to 80% faster for tag-heavy repos). Thank you @swift inlet https://dagger.io/changelog#faster-git-remote-fetches

MERGED faster listing of check and generate functions, especially noticeable on remote engines. https://dagger.io/changelog#faster-dagger-check-and-dagger-generate-listing

Thanks @swift inlet and @jagged flicker

[loud briar]

Think that git fetch change will be a sneaky little winner for us, we're fetching git repositories as *dagger.Directory inputs and they're tag-heavy

[azure hatch]

Hey - when you use Dagger on K8, when you create a new container in Dagger, is that spinning up a Pod in K8? I was wondering what that looked like and what connectivity they would have

[winter linden]

No, Dagger bundles its own container orchestrator and runtime. It talks directly to the kernel to start containers. It is like its own miniature (single node) kubernetes + kubelet all in one.

When you run the Dagger engine in kubernetes, you're only using kubernetes as provisioning. You could achieve the same result by spawning an ephemeral VM with a single privileged container inside.

This is also why the engine container needs to be privileged: it is a host service. Running it in a container is purely for convenience of packaging and distribution.

[winter linden]

And now all of the above is SHIPPED

Dagger 0.20.1 is out! https://dagger.io/changelog#0.20.1

And there is a new bonus section at the top of the changelog: features in development. https://dagger.io/changelog#dev

[hidden dirge]

Quick question on dagger checks and toolchains.

Is it expected that that the main module object is created when dagger check is run? I had assumed that this would be independent, so I could run dagger check without creating an instance of the main module object.

As of now, I see an error since I'm not setting all required module constructor arguments when running dagger check

May be because toolchain source is local in repo?

[winter linden]

@hidden dirge yeah this is a known issue, this is getting completely refactored away with modulesV2 (which will absorb and deprecate toolchains) https://dagger.io/changelog#modules-v2

The concept of "main module" disappears completely -> that becomes a workspace. So everything becomes more garnular and lazy as a result

[hidden dirge]

Thank you!

[bronze hinge]

qq - is Container use active?
I have a ponder -

1. I ask agent to make changes
2. spin up a web server to see it
3. then i merge them changes
4. cu delete some-env

THEN
**port is still running! **

👀 how do i kill it? it means the image is linguring somewhere - how can we do clean up proper - not just the worktree?

[warm wagon]

Sometimes I see this really long HTTP Get on "remotes.docker.resolver..."

What is this? Why's it taking so long on a "mkdir" call?

[strange lotus]

Any Dagger talks or booth at Kubecon EU / Amsterdam ?

[loud briar]

Dagger 0.20.1:

sh err hash_sha256_verify checksum for '/var/folders/1g/278n_lq91xg2q2d2gs5mw3cw0000gp/T/tmp.jXfYxvQYZb/dagger_v0.20.1_darwin_arm64.tar.gz' did not verify e735d38d50834f37265605a5ef6955a2f28bff4997f1e324d6de55cd8f0d5215 vs 58f4d034a869a7e49c851de05352ea9b9dc769f74ed35246f3dcb8cd29b0596b

brew install dagger/tap/dagger
==> Fetching downloads for: dagger
✘ Formula dagger (0.20.1)                                                                                                                                           Verifying    19.9MB/ 19.9MB
Error: Formula reports different checksum:  e735d38d50834f37265605a5ef6955a2f28bff4997f1e324d6de55cd8f0d5215
       SHA-256 checksum of downloaded file: 58f4d034a869a7e49c851de05352ea9b9dc769f74ed35246f3dcb8cd29b0596b

@winter linden Friday problems

[winter linden]

weird I upgraded yesterday on mac and it worked fine... We'll look into it

[cunning jolt]

I've seen the same. But re-trying it works. IDK why. We download from https://dl.dagger.io/dagger/install.sh

[loud briar]

I retried both several times, same issue

Back on 0.20.0 for now

[winter linden]

@sharp marsh 👆

[sharp marsh]

@loud briar should be fixed now. We had some old checksums cached in our CDN which we have refreshed a few minutes ago 🙏

[loud briar]

I'm off for a week, I'll update Monday 16th 😁

Maybe workspaces+modulesv2 is released by then 😉 🙏

[winter linden]

https://giphy.com/gifs/justin-hope-hoping-fingers-crossed-l0NwNrl4BtDD7JCx2

[humble sage]

I am running dagger over podman (podman machine) on OSX. Is there a way to make a container from an image stored in the podman engine from a Python module ?

I managed host | container-image localhost/plone:6.11 but I would like to check if an image already exist in my host/podman engine before building it from my Python module.

[tired moth]

@winter linden we would love to have access for cloud engines please let us know how we can use it and experiment and give live feedback.

[loud briar]

I think you might have confused Discord with LinkedIn 😉

[mild coral]

Hi @winter linden a quick question about modules v2. Having read part 1 and oart 2 of the design docs, everything looks great to me 🙂 I was playing around with the workspace type a few days ago and it looks great. I was wondering about the .dagger/config.toml file... will we definitely have to use the .dagger directory? Its not a deal breaker but we have been avoiding using it so far. Understand if this is required to make the feature work. If only the config file is required to make workspaces work, could probably live with that... but if we also need to put our modules in that directory then it might be a bit restrictive. Will we be able to put modules outside of .dagger and have them be part of a workspace?

Example:

Core-modules/ModuleB
Core-modules/ModuleA
Ci-modules/Go-ci
.dagger/config.toml

In this scenario, could the workspace at / include the other modules in the git repo?

[winter linden]

you don't actually need to keep modules under .dagger. It's just a default for convenience, at the time of module initialization. The workspace config file however needs to be at .dagger/config.toml

[mild coral]

Okay can live with that

[winter linden]

the good news is that you will no longer need a dagger.json at the root of your workspace. So from a "visible file pollution" point of view it's a win 🙂

[mild coral]

If we want to package a bunch of toolchains into a blueprint and install that blueprint in a bunch repos, how does that work in the new system? Do you install a workspace into the repo's workspace?

Thus the repo inherits the workspace config

[ancient ivy]

Hello everyone, have a stack of tests to dagger modules with coverage and reports?

[cunning jolt]

Modules V2: Bundling toolchains into blueprint

[humble sage]

@winter linden Would you have a hint ?

[drifting snow]

Hi, I have an issue where the default Dagger network CIDR overlaps with my AWS VPC CIDR (ie. 10.87.xx.xx vs 10.87.xx.xx).
This causes all requests made from Dagger (running on an AWS EC2 instance in a VPC) to the internet/VPC resources to be routed locally to the Dagger network, going nowhere.
I'm fairly sure this is the issue, as I've been debugging this for a while now trying a plethora of workarounds, and the only thing that solved the issue was running in a different VPC (with identical infra setup) with a different CIDR.

Is there any way to configure the address space that Dagger uses in its Docker network?

Edit: Going through the codebase I found the option to configure the --network-cidr option when starting a Dagger engine as a custom runner (https://github.com/dagger/dagger/blob/main/cmd/engine/main.go#L219), which is exactly what I needed. I couldn't find this in the documentation anywhere, but at least it is possible.

[stoic knot]

Somef Dagger config is passthrough of docker/buildkit, not sure if that is the specific case here. This is to say there is some configuration is documented on non-Dagger sites.

[sharp marsh]

hey! apologies for the late reply. We had a small team retreat and we're a bit behind on Discord messages. You can pass the podman socket to Dagger and query its API to check if an image exists beforehand? There's no dagger native API for that at the moment

[humble sage]

Thanks for answering

[cursive bridge]

I've recently started seeing logs like these in my dagger engine on kube:
level=warning msg="healthcheck failed" actualDuration="208.318µs"
level=error msg="healthcheck failed fatally"

My execution time has jumped as well. The dagger-engine pod has no defined limits, so it shouldn't be resource constrained. Any idea what could be causing that?

[winter linden]

⚠️ a new feature is dropping soon dagger check --failfast

Designed to give AI agents a faster feedback loop — instead of waiting for an entire suite to finish, agents get the first failure immediately and can start fixing it.

https://dagger.io/changelog/#fail-fast-mode-for-dagger-check

[steady cave]

hello pretty new here, I am trying to setup dagger cloud in depot, create a token in dagger and when navigating to depot dashboard, not find dagger under ci runners, I am using free dagger cloud, am I missing anything, any help is appreciated

[winter linden]

Hi Vishal and welcome. For Depot-specific support, you can go to #depot , we can't really help with that part.

Are you able to log into your Dagger Cloud account from your dagger CLI on the local machine? Are you seeing traces go through?

[steady cave]

figured, I can pass it through yaml via github actions workflow, so I think no longer a blocker for me

[tired moth]

Please help.

[winter linden]

just DMed you. sorry for missing

[tired moth]

no problem thanks a lot.

Which dagger version will have support for dang language?
And we need to write code written in ts again for better speed and reliability to use dang?

This will be dagger cloud exclusive feature or we will be able to implement same on premise?

If we are ditching buildkit then why can't dagger has its own container runtime also to make end to end workflows 100% dagger controlled?
You guys are building dang also then why not container runtime?
All stack managed by dagger team can make lightning fast devops stacks.
Thoughts?

[tired moth]

Can we use private npm modules published in github npm registery as module in dagger? @wispy tapir

[wispy tapir]

If you can configure your .npmrc with the right permission then yeah you can pull a package from anywhere.
Or you meant actual dagger modules?

[tired moth]

We have published dagger module as private npm module in github npm registery in repo r1, and want to use that npm module through npm install in repo r2's dagger module?
is it possible and correct way and as of now supported?

[wispy tapir]

Why you do not just install that dagger module using dagger install my-mod ?

[wispy tapir]

Trying to use a dagger module installed as an npm package would not work I think

Because you need to initiliaze that client so it can connect to the engine, which is what we do internally in the engine, and also you would end up with 2 different client, that's just simpler to install it with the regular way

[tired moth]

That was use case we didn't wanted to open source and keeping dagger module as private module in one repo and using it in other 50 diff repo is too much ops for token and https auth., so we were trying it to use as npm module only like our other npm private module published in github npm registery as private module, but it didnt worked

[wispy tapir]

For now it's not supported, if you want to expose private module as npm package, I would:

• keep my shared dagger modules in a private repo
• create a typescript project with an empty dagger.json, install all my private dependencies and use dagger client install typescript ... to generate client bindings to call these dependencies.
• publish that npm package that basically export the bindings with a connect function so you can use it from anywhere

The only issue you may hit is around module loading, but if they are all local and you also publish the dagger.json + the module's code, it might work

I can try to make an example for you tomorrow if you want

[tired moth]

not required as of now and if required then i will let you know. Thanks for your support.
and just to confirm if i have dagger module in git repo and want to use current dagger module feature then i need to add my token in all 50 repo right in which i want to use? if i dont want to open source then, right?

[wispy tapir]

Which token? If you’re host already has access to these git repository, your engine should be able to also

@swift inlet has more knowledge on the authentication topic, maybe he can give a more accurate answer

[cunning jolt]

and just to confirm if i have dagger module in git repo and want to use current dagger module feature then i need to add my token in all 50 repo right
If you are referring to PAT token, yes. But don't you need it anyway to clone those repositories? We don't set up any other token for dagger.

[wide atlas]

We have had problems with error 429 when using dagger-for-github. One reason for this is an unnecessary curl to get latest version, which is not used when having a specific dagger version.

So have now created a PR to improve this: https://github.com/dagger/dagger-for-github/pull/206

I did push it today so I have not received any reactions so far.

[winter linden]

Merged: stability fixes. https://dagger.io/changelog/#stability-fixes

[loud briar]

Quick one before I go down a rabbithole. Dagger (Go) modules and subpackages? Can I put subpackages in my module and use them as usual?

[sharp marsh]

hey MB! what do you mean specifically "use them as usual"?. The main caveat is that your module won't be able to return anything that's outside the main package for the moment

[loud briar]

Subdirectories with package somethingthatisntmain and using import module-name/somethingthatisntmain

Large modules getting messy, clear boundaries that would otherwise be subpackages. Thinking of doing that inside the dagger module if possible

[sharp marsh]

yes, you can use subpackages as long as none of your Dagger functions return a type that's outside the main package

besides that, there's no issue

[tired moth]

Are we going to add rva23 support in dagger? https://ubuntu.com/download/risc-v/canonical-built

[loud briar]

--progress=logs doesn't seem to show module logging e.g. fmt.Printf or similar. Only shows WithExec output?

[loud briar]

@winter linden Browsing the workspace docs, I don't see anything about multiple workspaces. Is this planned/possible? E.g. call a module with some args locally, and some slightly different args in Gitlab? Or as a light alternative, what's the prioritisation of inputs? If I set up a workspace for local, and in my .gitlab-ci.yml pass those inputs via cli (e.g. call <func> --parameter-that-is-in-config-toml <value-different-from-config-toml> which one is prioritised? If it's CLI that's good, if it's config.toml that limits me considerably

[elfin frigate]

mind opening an issue with a repro?

[loud briar]

Ignore that one, found the issue as soon as I put a small repro together

[elfin frigate]

https://tenor.com/bTJv7.gif

[winter linden]

CLI will override config file. And also, config fike will support multiple environments each with different config values. So you can do `dagger --env=gitlab-ci' for example

[loud briar]

Good news on both 🙌

[cursive bridge]

I'm running the engine locally via k3d (kube inside docker) and trying to mount my local storage for dagger so see if that improves performance. I'm getting the following error from the engine:

! failed to sync: failed to set content hash xattr: operation not supported

I ran into a similar issue when using k3ds local storage, but it was a permissions issue. Is this in the same vein and should be ignored (and an issue should be created) or something else?

I'm running engine version 0.20.1

[loud briar]

A new release of dagger is available: v0.20.0 → v0.20.3-20260319160715-dev-fdfcf990a3d5 😅

[elfin frigate]

Whoops sorry about that - bumpy release, that fdfcf990a3d5 commit is main. Just need to repoint latest to the proper v0.20.2 tag. Working on a fix!

[chrome moss]

Probably a dumb question -- How can I disable the debug/verbose logs when running dagger in ci like gitlab? I have tried adding progress=plain to the CLI command, and changing the engine config to say debug = false, and neither of those worked. We are running a dagger engine in a docker vm that we connect to via gitlab runner.