@shykes here ya go!

Nice! Based on your implementation work so far, does it seem doable in a robust way? Anything notable that you noticed? Design tradeoffs, feasability issues?

One question in particular: how should we (and can we?) handle multiple levels of depth? For example in this case:

actions: {
  frontend: {
    build: {
      ...
    }
    test: {
      ...
    }
}

Ideally dagger help do would output only one command: frontend.

Then dagger help frontend would, in turn output two commands: build and test.

Do you see any obstacles to implementing it this way?

I don't see any issues right now but will try and report back. Until then it's worth noting that the form dagger help do panics where dagger do --help does not. It will take me a bit to figure that one out, but will try the multiple levels with the latter form.

POC looks good to me.

Some suggestions regarding the architecture: one outstanding issue I see is we have a custom "actions scanner" within cmd/do which is separate from the "core actions scanner" we have in the runtime (e.g. cue flow).

Knowing about actions is not only useful to dagger do but will also be useful to the rest of the runtime (e.g. structuring logs, error messages, etc).

The Actions API proposal helps formalizing that, but in the meantime, I think we can achieve something very similar by leveraging cue flow (credits to @shykes for the idea).

In a nutshell:

• plan.Plan could expose an Actions() function, returning the list of actions in the plan
• Each Action would have a Children(), containing sub-actions
• To scan for actions, we can use flow -- the same instance we use for executing
• Flow provides some nice introspection capabilities.,Tasks() returns the list of detected tasks. Each Task provides a list of Dependencies() along with the task Value (e.g. can be used to introspect the docstring)

The naive implementation (without Actions API) would be to use flow to scan for "core actions" (e.g. tasks) and then assume every parent in the tree is an action as well.

To illustrate:

actions: {
		web: frontend: {
 			// Build via yarn
 			build: yarn.#Build & { ... }
...

• flow would list actions.web.frontend.build.container._exec as a "core action" (_exec task somewhere down yarn.#Build)
• We use this to build a "graph" of Actions, assuming (for now) parents are actions. In this case, "web" is an action with "frontend" as a child, and so on and so forth until web.frontend.build.container._exec
• While we're building this graph, we can add additional metadata from CUE values. Docstring is an example. The package import path is another (e.g. which package defines the CUE value)
• We can then use this information for display in dagger do -- for instance, skip actions that are defined in external packages (e.g. we'd show web, frontend and build, but skip container and _exec since they're defined outside)

Once we move forward with the Actions API, we'd only need to update the core logic in plan.Actions and it will be reflected in dagger do and other usages.

FWIW, I tested on one of my sample config it works great. LGTM on my side.

✔️ Deploy Preview for devel-docs-dagger-io ready!

🔨 Explore the source changes: 6cdf132

🔍 Inspect the deploy log: https://app.netlify.com/sites/devel-docs-dagger-io/deploys/621e7b9d5e9fae00074c149a

😎 Browse the preview: https://deploy-preview-1648--devel-docs-dagger-io.netlify.app

Nice work!