#root resolution strikes again
1 messages · Page 1 of 1 (latest)
The way it works today is by taking the module path, and working upwards until we hit a dagger.json or a .git dir, and then we treat that as root. But if we don't find one above, then oop, that's it, we treat the module as a root dir.
The issue we hit is that if we mount the repo itself into a dagger dev container, like in https://github.com/dagger/dagger/pull/7771
Then we don't mount the git dir, since it's so large. But, then we can't correctly establish the root, and so we get insane go dependency issues because the root is the dev module: https://github.com/dagger/dagger/actions/runs/9760173624/job/26938409245?pr=7771
I can resolve this by just mounting the .git directory through - but also, it feels like kind of a crap exerience for users, understanding root resolution is really not very fun, the implicit .git magic is not super fun when you don't copy it around (and it's huge, so it's annoying to do).
I kinda don't have great solutions in my head, the best I can think of is to try and find the "highest" dagger.json file, and use that as the root. So building /home/jed/project would determine the root by looking for /home/dagger.json, /home/jed/dagger.json and /home/jed/project/dagger.json, with the first found one being the root for that module. This has other issues though...
I'm unsure whether it's related or not, but when trying to use the CLI in bin/dagger, I get an error, as I'm not sure what directory "view" I should be passing as an argument
https://dagger.cloud/wachines/traces/4df6beb9d4434995332bbf8f7577764f
not sure how to properly use views as they are not documented
https://github.com/dagger/dagger/issues/7489