Workspace for cross-repository builds

[lofty patio]

The new Workspace type is awesome, but it's always set to the root of the repo AFAIK.
This covers most cases, but I did have to implement my share of cross-repo builds in past years.
I wonder if being able to set the Workspace root explicitly via something like --workspace-root=... would be feasible.
We can already pass directory args that are outside the repo, this doesn't seem too dissimilar.

[azure oar]

See the companion PR: https://github.com/dagger/dagger/pull/11812 🙂

Also: #1476721965279612970 message

[lofty patio]

does that mean if I have:

• ~/projects/all-repos/.dagger/config.toml
  -~/projects/all-repos/repo1/.git

and run dagger running from ~/projects/all-repos/repo1/project1 my workspace root will be ~/projects/all-repos?

[azure oar]

The workspace root will be determined by where you initialize it. By default it will be the repo root, but you can specify a subdirectory in monorepo situations. Workspaces are a new concept that we are introducing in that PR. It will be marked by .dagger/config.toml: a new workspace config file where you can set workspace configuration like which modules to install, per-module config, and so on

(oh sorry you already knew that, missed your pasted .dagger/config.toml line

[azure oar]

Good question 🙂 Which one is the right answer in your opinion?

I think as implemented, the answer is yes. But we haven't explicitly defined the desired behavior in this case

[lofty patio]

Well… it’s the better of the two, but not my favorite 🙂
this means a single workspace which also defines modules for everything, which hasn’t been very useful for my use-cases. I would more often have workspaces and modules being contextual based on the project in the current directory, but with possible access to directories above the current one.
So ideally I’d have

• the module loaded based on the current directory
• workspace root defaulting to the repo root, but overridable. Maybe an optional entry in .dagger/config.toml?
• easy way of knowing the relative path from workspace root to the current directory

I think one of the challenges migrating a build to dagger is adapting to things being hermetic, these 3 should help.

[azure oar]

you can have as many workspaces as you want, just drop .dagger where you want a workspace

the .dagger is the repo root. If there is no parent .dagger, we fallback to parent .git

[lofty patio]

Yes, but .dagger/config.toml also defines what modules to load as far as I understand. So it’s tying the ‘build script’ to the workspace root. I’d like these two to be independent.
Maybe I’m missing something

[lofty patio]

To put it another way I may have 2 projects using different builds, but requiring access to the same root directory somewhere up the tree.

[azure oar]

First of all: sorry if this is not clear, making sure it's all clear and consistent is one requirement before we merge 🙂

[azure oar]

This is why we have decoupled 1) filesystem boundary (how far up can the paths go), and 2) workspace boundary (what is the current configuration context)

You can drop a workspace (contextual configuration context) anywhere. But the filesystem boundary will always be the parent git repo. Which means any module running in your repo, regardless of which module configured it, can always access files from anywhere in the repo (because that's the filesystem boundary)

[lofty patio]

So if I have path/to/repo/project1/.dagger/config.toml the Workspace.Directory(".") still points to path/to/repo?

btw thank you for the time you're spending here

[azure oar]

Maybe we should simplify the model even further:

• No filesystem sandbox: all paths are resolved directly in the workspace's host filesystem or remote git context (eg. /Users/idlsoft/myapp/foo/bar or https://github.com/idlsoft/myapp)
• Workspace.path returns the absolute path of the workspace root, eg. /Users/idlsoft/myapp/foo/bar/my/workspace)
• By default, paths outside of the workspace's git repo will fail - but maybe configurable to make exceptions

[azure oar]

As I proposed in #1476721965279612970 , we're going to refuse to resolve relative paths (including ".") because we're not 100% sure what they should resolve to

[lofty patio]

So, assuming my git repo root is ~/myapp and workspace is under foo/bar/my/workspace:

• Wokspace.Path returns a string /Users/idlsoft/myapp/foo/bar/my/workspace
• Workspace.Directory("/foo/bar") allows me to see files in the (grand)parent directory.

and according to your last bullet point with some additional configuration one may even read files outside ~/myapp

[azure oar]

As implemented today

• Workspace.path does not exist.
• Yes,Workspace.directory("/foo/bar") allows you to see files in the (grand)parent directory, up to the git boundary (/)

In hypothetical "host mode" alternative design

• Yes, Workspace.path returns /Users/idlsoft/myapp/foo/bar/my/workspace
• No, Workspace.directory("/foo/bar") would attempt to read /foo/bar in your actual host filesystem, and fail
• ws.directory(ws.path() + "/foo/bar") would allow you to see files in the (grand)parent directory

[lofty patio]

you mean ws.directory(ws.root() + "/foo/bar")

that's awesome!

I confused ws.path with ws.root, sorry

I really like "host mode"

especially if the caller can explcitly allow grant to directories above the git root

[azure oar]

Yeah one or the other - bikeshedding

[azure oar]

The downside is that untrusted workspaces can mess you up. We'll need a trust model similar to what IDEs do

And, if you want a local config for overriding a workspace config, we'll need to define a config file format for that, and figure out how that config can reference workspaces to override (probably by local path, but then you're responsible for keeping that in sync if you move workspaces)

But, it does make the model simpler. Less concepts to juggle

[lofty patio]

could trust be as simple as FindUp(".dagger-root") || FindUp(".git") and that's the boundary?

[azure oar]

For files, yes, but there is also module configuration - which means loading secrets, unix sockets, tcp tunnels into module constructor arguments.

Basically workspaces are not sandboxed (unlike modules)

[lofty patio]

hm... I feel like these kind of things can be machine-specific and tricky to configure in a source-controlled toml file, you'd need to provide them as part of the call, no?

[azure oar]

Usually it's a mix of env-specific and project-wide values. We are adding first class support for multiple environments - just an [environments.*] key in the toml, where you can set config overrides. Then dagger --env=FOO.