#Experimental TUI seems to clear CacheVolume?

1 messages · Page 1 of 1 (latest)

autumn steppe
#

I am seeing this weird issue when I try to run a maven build. I am creating a CacheVolume for the .m2 cache and I have several "stages" where I do multiple mvn commands (like compile, verify etc.). When I run go run main.go consecutively, the cache volume is preserved between runs and maven doesn't re-download dependencies. But when I do _EXPERIMENTAL_DAGGER_TUI=true dagger run .... The cache (including the docker image cache) seems to be cleared and everything is downloaded again. But subsequent runs of the TUI shows that the cache is preserved. If I keep switching between TUI and non TUI I don't have a cache between the runs.

Doesn't feel like expected behavior.

TLDR; SOLUTION: #1105952785331142776 message

bold holly
#

hm, are you passing any options to dagger.Connect in your code?

autumn steppe
#

Yes this is my dagger connect

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

bold holly
autumn steppe
#

ohhh

bold holly
#

is it possible to refactor away from the implicit workdir and switch to using Host.Directory instead?

#

we're discussing moving away from these per-session options; it's come up in a few different contexts. Workdir is a bit of an old pattern, which existed before the API supported accessing arbitrary host paths

autumn steppe
#

hmm, the reason for me to use workdir is because I want the pipeline code contained within a subdirectory of the actual repo. I remember trying to access the parent directory with a relative path and it didn't work.

bold holly
#

oh yeah that's kind of a strange special case in hindsight. it will happily accept an absolute path, at least

autumn steppe
#

Having to provide the absolute path is not great because I'm trying to make this run on arbitrary developer machines 🙂

bold holly
#

the reasoning for disallowing ../ was something related to future plans about keeping extensions constrained to an initial workdir, if I'm remembering right (cc @daring owl)

bold holly
autumn steppe
#

that may work.. I had to give the workdir to the dagger run command also. I assume i'll have to give an absolute path there too?

daring owl
#

General idea is to move all session configuration to dagger run flags right @bold holly ?

#

so in theory you could have an equivalent to each of those parameters, just not in the code?

bold holly
#

yeah, in my mind it's either deprecating/removing the need for them or having them come from the CLI

bold holly
#

WithLogOutput for example may be rarely useful as people switch to dagger run/dagger do

daring owl
#

can’t wait for dagger do on top of this 😍😛

autumn steppe
#

I don't even know what dagger do does but i'm excited 😄

bold holly
#

so there's WIthWorkdir, WithConfigPath, WithNoExtensions, and WithLogOutput. even fewer than I thought

bold holly
autumn steppe
#

do I remove WitLogOutput also? or does it not matter?

bold holly
#
  • WithConfigPath: already has --project (and no one should be using it anyway)
  • WithNoExtensions: I don't think I've ever seen this used
  • WithLogOutput: replaced by TUIs (or generally ways to process output in the CLI)
  • WithWorkdir: replaced with --workdir and/or using absolute paths everywhere

@daring owl do you think we still need the ../ restriction for Host.Directory? it's a little funny/unintuitive that you can just resolve it to an absolute path first. I remember extensions concerns were involved here but the details are fuzzy.

autumn steppe
#

looks like I can't even have WithLogOutput. in the dagger.connect. Wiped the cache again. I'm re-running now

bold holly
#

I'd be surprised if that was causing any behavior change, I think they're just ignored

autumn steppe
#

so after I remove the workdir from dagger connect. Should I be able to run both TUI and go run without invalidating the cache? Or am I supposed to exclusively use TUI if I am doing so?

bold holly
#

my guess is the cache miss/cache hit behavior was a red herring and running with a different workdir was the root cause for cache busting, but not sure

#

in short, there should be 0 behavioral difference between using the TUI and not using the TUI

autumn steppe
#

weird.. each one is creating a new instance of the engine

#

huh... dagger run is spawning registry.dagger.io/engine:main go run is spawning registry.dagger.io/engine:0.5.1

#

so, no wonder it forgets my cache

bold holly
#

oh, yeah, we need to handle that better 🤔

#

your dagger binary is probably built from source, whereas the SDK is using the shipped version

autumn steppe
#

dagger binary is from brew

bold holly
#

@green topaz 👆 something we'll need to keep in mind as people adopt dagger do and dagger run (dagger CLI being out of sync with their SDK version)

autumn steppe
#

I dont' have any dagger env vars set either.

#

For now I can run with the RUNNER env var and see if they both pick up the same

bold holly
#

what version of the formula do you have installed?

autumn steppe
#

Homebrew? Latest I guess? I just upgraded it today.

#

I stepped away for a bit but I can check the versions a bit later

bold holly
#

oh, I see what went wrong. two different code paths don't agree on whether a Version const should be v1.2.3 or 1.2.3

daring owl
bold holly
autumn steppe
#

Fantastic! Thank you!

bold holly
tight spear
#

I was having this problem too, thanks for the fix vito 👍

green topaz
green topaz
autumn steppe
#

With the latest dagger CLI via brew and the latest engine I can confirm this issue is resolved. thank you all for the quick fix! 🙂