Trying to build and run test inside dagger.

[stark path]

I have a monorepo and am learning dagger 😉
apps/sync-clean-data/ is my first candidate

I now have a build and push that works locally and am integrating it with GitHub actions.

I have initialized from sync-clean-data/dagger with the name dagger/sync-clean-data

My problem is that I can not build from inside dagger nor test (which I am after for now).

build.go:24:2: package dagger/sync-clean-data/internal/dagger is not in std (/opt/homebrew/Cellar/go/1.23.5/libexec/src/dagger/sync-clean-data/internal/dagger)

Not sure how to handle this?

I did try to replace the import by dagger.io/dagger, but then the build and test were working ( I had to create dag and main but then dagger was broken ...)

Any help/best-practice would be helful and welcome.

[uneven widget]

@stark path could you give more details on what commands you use to run your dagger build & push locally? Normally once it runs locally, it should also run in CI, since Dagger containerizes all your dependencies

[stark path]

to use dagger I chdir in monorepo/apps/sync-clean-data and run
dagger call build, push, test, etc.

=> it works fine and also on my CI pipeline (not yet solved the authentication to the docker registry, etc. but this is for later !)

Now I am trying to build from within the /monorepo/apps/sync-clean-data/dagger directory as I have a few functions I want to test there.

So from the dagger directory I try to run:
go build . so that I can go test .

Not sure this is doable/advisable.

What I am trying to do is to test some of the func() in my dagger pipeline

This is from the dagger sub directory that I have the error mentioned above:

❯ go build .
build.go:24:2: package dagger/sync-clean-data/internal/dagger is not in std (/opt/homebrew/Cellar/go/1.23.5/libexec/src/dagger/sync-clean-data/internal/dagger)

[uneven widget]

So you're trying to go build the source code of your dagger module, as opposed to running it with dagger call?

[stark path]

Exactly

[uneven widget]

And this is because you have unit tests to test the module itself, ie you have somethingsomething_test.go and you're hoping to run those tests?

Unfortunately this doesn't work at the moment... Because the way our SDKs work, they provide a special build and execution environment that is containerized, and without that environment you can't easily build the code

What's missing is an easy way to run go test within the Go SDK's containerized environment, so that you can write your tests the usual way. There's an issue tracking that: https://github.com/dagger/dagger/issues/6724

sorry for the inconvenience

At the moment what people do as a stopgap, is create a separate module (typically in a subdirectory eg. ./tests or ./dev, and have that module import the main module as a dependency, and call its functions from there to test that it works properly. Then you call those tests via dagger -m ./tests call test

[stark path]

Thanks a lot!
=> This is super helpful and greatly appreciated.

[uneven widget]

Here's an example of such a tests module: https://github.com/sagikazarmark/daggerverse/tree/main/go/tests

[stark path]

So in essence I have to refer to the parent module via the

    {
      "name": "go",
      "source": ".."
    }

no need for a dagger init in the submodule?

[uneven widget]

yeah you need to dagger init. Then you dagger install ..

dagger install allows any module to install any other module as a dependency (local or remote)

install will generate bindings for calling the dependency from dag.

So for example if you dagger install github.com/dagger/dagger/modules/wolfi, then your Go bindings will include dag.Wolfi()

note that local dependencies are only allowed within the same git repo

[stark path]

Thanks a lot.

Follow-up question 😉

I have multiple repos (and one monorepo) => I was thinking to have all the dagger code in a dedicated repo.

The pipeline would checkout the repo in a GH Action (first thing) and then call the correct action with the desired arguments. We can use the ${{ secrets.GITHUB_TOKEN}} available in the gh workers and then do everything from within the dagger pipeline.

=> Is this setup recommended/typical or is there a better way to handle this use case?

[rose stump]

So you're thinking repos like this?

the-monorepo
repo-a
repo-b
dagger-stuff

and functions in the dagger module (in it's own repo) would take in a directory argument where you'd provide on of the repos, for example?

That could work, especially if all repos can be handled by the same functions. But since at least one of them is a monorepo, I suspect they're not all that uniform.

You could also put a dagger module in each of your app repos. What we call "daggerizing" an app.
If you dagger init --sdk go in each of the-monorepo, repo-a, repo-b, etc, then you'd end up with a .dagger dir in each alongside your app where you could develop the functions for those specific projects.

repo-a ➤ tree -L 2 -a
.
├── .dagger
│   ├── .gitattributes
│   ├── .gitignore
│   ├── dagger.gen.go
│   ├── go.mod
│   ├── go.sum
│   ├── internal
│   └── main.go << your module's functions here
├── LICENSE
├── README
├── dagger.json  << points to .dagger mod code
├── myapp
└── mydeps

You could put common functionality in a module that you dagger install in the others.