#Struggling with dagger cli and workdir

1 messages · Page 1 of 1 (latest)

west night
#

I have a minimal go project with this layout

├── app
│   ├── go.mod
│   ├── go.sum
│   └── main.go
└── ci
   ├── go.mod
   ├── go.sum
   └── main.go

The actual pipeline is a separate go module inside the ci folder. Executing the pipeline via ...

cd ci && go run main.go

... works as expected when in ci/main.go the dagger client connects using the workdir (relatively set) set to the app folder like this

client, err := dagger.Connect(ctx, dagger.WithLogOutput(os.Stdout), dagger.WithWorkdir(".."))

Is it possible to run this pipeline via dagger run? I tried several variations with dagger run --workdir but it didn't work.

Inside the ci folder dagger run go run ./main.go states

panic: cannot configure workdir for existing session (please use --workdir or host.directory with absolute paths instead)

Could someone explain how this session mechanism works? As far as I understand the dagger cli starts it's own session and the workdir could not be set via dagger.Connect(...)?

Is there a way to query via the sdk if there is already an existing session?

As another attempt I removed the dagger.WithWorkdir('..') argument from dagger.Connect(...) and tried setting the workdir via the --workdir flag only. E.g. in the project root folder

dagger --workdir ./app run go run ../ci/main.go fails with ./ci/main.go:9:2: no required module provides package dagger.io/dagger

It seems that the split into separate go modules might not be possible? Maybe i miss something very important here?

Thanks in advance for any help?

gleaming siren
#

Played around with this a little bit, and I don't think this is much of an issue with Dagger as it is with Go. go run is looking for the go.mod in the working directory, and it's mismatching with the one the ci/main.go expects to receive. I suspect this would work if you built ci/main.go instead and ran it as its compiled executable.

I think the only way to get around this is to use go workspaces. If we init a workspace at the root using go work init then add the two modules using go work use ./app go work use ./ci, we can then run dagger run go run ./ci from the root. I don't think there would be a way to scope into the ./app workdir directly though using dagger run.

I understand the want to separate go.mod files but lets also consider a root go.mod. Go only builds using dependencies that are imported by files including in the compilation. Go doesn't have a concept of dev dependencies so things like testing frameworks are including in the same go.mod as everything else. At build time, when test files are excluded, so are the packages that are referenced inside of them. With a centralized go.mod and a simple hello world in the app/main.go, when we run go build ./app the output file is 2MB which lines up with if the go.mod were separated. Same with ci/main.go, where the file size is 8.6MB. So it'd be safe to include dagger into a central go.mod.

Hopefully one of these two (and a half?) solutions work for you.

molten pier
#

👋 you can accomplish this by dagger run go run -C ci main.go

gleaming siren
west night
#

Awesome ! Many Thanks @molten pier that works!!! Didn't know that flag.