I was expecting that if dagger.WithWorkdir was configured on dagger.connect would allow to avoid --workdir to the dagger cli.
#WithWorkdir not respected: dagger.Connect(ctx, dagger.WithLo..., dagger.WithWorkdir("../../"))
keen prawn
keen prawn
shouldn't client.Directory() point to ../../..? Seems that it still points to the directory where dagger is running from.
agile grail
Did you run with dagger run?
keen prawn
Yes, I did. Passing --workdir=../../.. to dagger works, but the reason why it does is still a bit unclear to me.
fleet temple
👋 that's because the CLI workdir has precedence over the SDK one when the CLI is used. I don't think we have this documented though
I'll create an issue for this
@keen prawn are you using the latest dagger SDK version? Seems like this issue should have been address here: https://github.com/dagger/dagger/pull/5126 I'm doing a quick test now
just validated this is the case:
130|marcos:tmp/test (main) (⎈ |kind-kind)$ dagger run go run ./ci/main.go
█ ERROR go run ./ci/main.go
┃ panic: cannot configure workdir for existing session (please use --workdir or host.directory with absolut
┃ e paths instead)
┃ Please visit https://dagger.io/help#go for troubleshooting guidance.
┃
┃ goroutine 1 [running]:
┃ main.main()
┃ /tmp/test/ci/main.go:15 +0x1079
┃ exit status 2
┻
exit status 1
$ dagger version
dagger v0.6.2 darwin/arm64
I can use filepath.Abs() to convert my relative paths to absolute. But it still feels counter-intuitive that client.Directory() / client.Host().Directory("."), do not resolve to the directory set when we defined the client.