How to do things like "run `build` for all projects", etc in a monorepo?

[eager galleon]

I have a monorepo with multiple projects, and let's say I want each to have a lint function, a test function, a build function, and so on. Then I might want to say "lint projects A B C", or "lint all", or "lint and test all".

What's the best way to do it with dagger?

[compact igloo]

• Today you do it yourself in code (I can point you to examples). It works but is quite custom and requires boilerplate
• We are actively working on making this simpler with core features.
• May I ask if the functions you want to call all qualify as "checks"? Ie. something that is green or red. As opposed to collecting and aggregating artifcts for example (harder to standardize)

[eager galleon]

I saw the dagger checks PR and yeah, once it lands I will probably switch to that

[compact igloo]

ha ha nice 🙂

[eager galleon]

But I'm asking also cuz I felt like I was missing something obvious

[compact igloo]

I'm actually refactoring our own CI (which has a lot of this kind of boilerplate) in preparation for checks. So this is literally my topic of the day

[eager galleon]

ok gotcha

[compact igloo]

In our case it's to run various functions across all SDKs

For example you can try this:

dagger -m github.com/dagger/dagger call lint-sdks

And it will run all linters across all SDKs

(edit actually I removed the global lint in preparation for dagger checks.)

Here's the corresponding code: https://github.com/dagger/dagger/blob/main/.dagger/stopgap_checks.go#L94-L115

[eager galleon]

do you also use it when running linting locally? like in general do people try to use dagger call ... as much as possible during local dev, or do you still do golangci-lint ... (or whatever) locally and dagger call ...on CI?

[compact igloo]

I personally use dagger call all the time for everything. But, it depends on how well the native toolchain works, and how dependent you are on e2e integration in your devloop

In some cases you can develop on your native toolchain for days without touching other components - in that case you would typically only dagger call (or soon dagger checks 🙂 ) towards the end of a task, in preparation for sending your PR

In other cases (and I am in that case) integration is a core part of the devloop - for example complex system software like Dagger, or software with lots of cross-platform dev dependencies. In that case you dagger call all the time

I think the sweet spot for most teams will be:

• During your devloop use dagger as much as makes sense - each team is different
• Before submitting a PR, run all the checks with dagger checks, and possibly other integration tasks (for example we generate all SDKs with dagger call generate). dagger docs server up will run a local dev instance of the docs server for manual review; etc. This will integrate all the toolchains, beyond the one you are familiar with.
• In CI, the same checks will be run

Separately, when we release / deploy we have dagger functions for that purpose

Also you can get a full interactive playground from any version of the repo with this single command:

VERSION=main
dagger -m github.com/dagger/dagger@${VERSION} call playground terminal

Which is always nice 🙂

[eager galleon]

I will reveal my use case

I do all my development by asking agents to do stuff and I never touch the editor myself

and what I really really want is to bind the agent with iron shackles so that it doesn't decide on the ad hoc basis which linters it wants to run today, or "looks like Go isn't found I'm going to use random Go I found somewhere else" etc etc etc

Dagger seems to be good for this? maybe? so it's still technically for local dev (and speed is important) but it's not for human dev

[compact igloo]

Yes 🙂 This the dream

[eager galleon]

ok neat

[compact igloo]

Paging @distant cave who exclusively runs his coding agents inside Dagger with the "shackles"

Basically you can use any dagger module as a sandbox for a LLM. Functions in the module are available as tools - and nothing else

[eager galleon]

hmmmmm

[compact igloo]

Dagger is a unique position to solve this problem, because basically coding agents merge 1) development loop and 2) delivery loop. They need a "context engine" which can handle that. Which by chance is what we've been building 🙂

[eager galleon]

I didn't think about running agents inside dagger

[compact igloo]

If you want the shackles, you have to. We also have a MCP integration (dagger mcp) which is the same plumbing... but it's optional... you still have to beg the agent to use the shackles, and the other tools are still there. It works but it's less reliable

[distant cave]

if you want to try it out: dagger -m github.com/vito/dang/mod/dev call for-module --module ./ --source ./

that'll start a Claude Code -like agent equipped with tools mapping to functions provided by the module (and --source ./ being the workspace)

eh actually that module might expect a github token at the moment, feel free to set garbage if it asks, the paint is very wet

[compact igloo]

what's the difference between--module and --source ?

[distant cave]

one arg is Module (module providing tools), the other is Directory (the env workspace)

would be nice to just have one, I hoped to get to the context dir from a Module but that only has the module source code in it. could technically do Directory.asModule and I guess that'd support git remotes too

[compact igloo]

May I suggest calling it --tools 🙂

will try it too!