Is it ready to be reviewed? Last one was a draft and I still see unfinished things in the code

@TomChv Not yet. Still need a run through of the DX with @shykes. Then I'll clean up all of the code and submit for review. I'll change it to draft. Forgot to do that when I created a new PR.

Hey @jlongtine, I need this for #1351. What do you need to move forward?

Hey @jlongtine, I need this for #1351. What do you need to move forward?

We went through DX together, it all looks good, no issue on my end (unless something changed in the last couple days).

@helderco @shykes I had set this aside to focus on #1711, then got caught up in the gears on that one. I was planning on trying to get unblocked there, then moving back onto this. Happy to re-arrange priorities, if need be.

@helderco After a chat with @aluzzardi, I'm going to focus on this and get it across the line.

We're rooting for you @jlongtine :)

Because I'm actually checking to see if the request path is an action (i.e. has a cue/flow Task in it), this causes a behavioral change (hence the change in bats tests). I'm not currently sure how to maintain the current main behavior and give nice help messages when someone asks for an action that we don't have in our data structures. This is related to #1789.

I see. I think that's ok to change. Instead of allowing to dagger do a scalar, only allow running actions (i.e., anything that includes a core action no matter the depth). Makes sense to me.

In the case of the push.cue test:

		pullOutputFile: core.#ReadFile & {
			input: pull.output
			path:  "/output.txt"
+		} & {
+			// Check output file in the pulled image
+			contents: randomString.contents
		}
-
-		// Check output file in the pulled image
-		pullContent: string & pullOutputFile.contents & randomString.contents

@helderco That test is still valid, actually. CUE will fill those values and check that they are the same.

I know, but you seem to have had to change bats to target pullOutputFile instead of pullContent. Wasn't that because you can't target pullContent with this PR?

I know, but you seem to have had to change bats to target pullOutputFile instead of pullContent. Wasn't that because you can't target pullContent with this PR?

Yes, that's correct.

Just flagging a potential issue: I've actually ended up writing pure cue actions in at least once case, when I only process inputs without the need for core actions. This is how I hit #1789. Is it possible to ensure that regular structs are taken into account by dagger do, and listed in the help message?

I think in the future this problem might go away with #1598, if it defines an explicit dagger.#Action that action developers must extend. Then we would no longer have to guess: only instances of that definition would count as an action.

Is it possible to ensure that regular structs are taken into account by dagger do, and listed in the help message?

It would be great, problem is, cue/flow doesn't run those.

Is it possible to ensure that regular structs are taken into account by dagger do, and listed in the help message?

It would be great, problem is, cue/flow doesn't run those.

I don't think it needs to, as long as it runs the client actions wired to it (both inputs and outputs).

Yes, true. There's still the case of targetting a scalar or something that doesn't reference core actions eventually, but maybe that's out of scope for this PR.

Anyway, what should happen with pullContent above? I'd say no inputs/outputs in that case. You can wrap a struct over it to enable them.