What's the primary use case for the

build

field on actions. The docs are a little unclear on this: > Specify a Build action, and resolve this action from the context of that Build. > For example, you might create an exec Build which prepares some manifests, and then reference that in a kubernetes Deploy action, and the resulting manifests from the Build. If I e.g. have a Test action of type container that depends on some build, should I specify that here? Or should I rather just set the image for the Test action like so:

- kind: Test
    name: my-test
    type: container
    dependencies: [my-build]
    spec:
      image: ${actions.build.my-build.outputs.deploymentImageId}
      args: [npm, test]

The base path (i.e. source path) of the Build action referenced by name in the

build

field is used as the base path of the Test/Run in question. By default, runtime actions (Tests and Runs) use the base path of the action itself as the working directory for e.g. the CLI tool that's being called in the plugin. But if

build

is set, the base path of that build action is used as the working directory instead.

Hmm ok. So this is exactly the same as setting as

source.path

?

Hmm, yeah. Haha. Looks like that's the case (just did a reference search in the codebase). So I think we could simplify this.

And back to my original question: What's best practice for specifying what image to use for a Test action of type

container

. Would it be to have it depend on a Build action and do

spec.image

? Or rather just build the test container "on demand"?

I.e. the

build

  field is currently only used for calculating the source path. So that override can equivalently be provided by setting

source.path

, as you say.

For context, we had a ModuleTemplate in the platform repo that had several tests and tasks. Now that I'm splitting that up into actions, I'm not sure how to handle the tests that belonged to the original template. This is because the

Test

that belongs to the template depends on the

Build

from the same template, but I can't set the build as a dependency because it would require unresolved template strings in the dep array.

dependencies: ["${actions.build['${parent.name}']}"] # <--- This won't work

Hmm, do we need that to construct the name of the build to reference in the dependency declaration? How about

dependencies: ['build.${parent.name}']

... or whatever the formula for the name of the Build action is?

Ah right. I think I'm the one missing something obvious. 🤦‍♂️ I think I just copied this from the original version as is. Jesus, that was silly. It's been days knee deep in this config stuff so I must've had my wires crossed

All good! Goes to show that deciding which template expression to use is tricky, even for us who work on this thing. If there was first-rate IDE autocompletion for the types of the template expressions, all this would be so much more intuitive. There's a lot of implicit structural typing going on here.

For sure! We'd need a proper LSP for that right? And I ain't talking spaces princesses either.

hehe