Enable selecting component to execute

[fibonacci1729]

Tracking this so it doesn't get lost.

Currently the trigger can execute only the first command component. We should define a trigger flag --id/--component-id that specifies which command component to execute.

[karthik2804]

implementation detail question. I can imagine not having to specify anything if there is only one component. In cases where there are multiple, would it be required to specify the ID, or if it is not specified, we fall back to executing the first component? I think we should make it compulsory in the case of multiple components as otherwise, the behavior can be confusing if the user changes the order of the components specified.

[fibonacci1729]

I agree. In the case of >1 components require the component selection flag.

[itowlson]

Is this the right idiom? Suppose, in my manifest, I write:

[[trigger.command]]
component = "do-the-thing"

[[trigger.command]]
component = "do-the-other-thing"

It's not very obvious what this could mean.

In any other trigger, that means all those triggers are instantiated and respond to events. The equivalent semantics would be that all command components run.

But then again, I am not sure what a meaningful use case is for multiple commands in a single application. Perhaps multiple instances of the command trigger should be a validation failure.

[karthik2804]

It could potentially be useful to package multiple command into a suite (I would like to imagine something like busybox) which could be a singular artifact when published via oci, so that I do not need to download multiple images?

As far as the manifest in the example provided, I would hope the author has descriptive name 😅 .

[fibonacci1729]

One usecase I can imagine is not needing to duplicate variable definitions across each application on a per command basis. So multiple commands in an application can share a singular set of variables.

[radu-matei]

(my comment is not a feature request, just exploring the usefulness of multiple components)

There are two main scenarios I can think of here:

• in #7, we're exploring potentially the ordering of execution of a command, basically creating something like "init components" for Spin. Having multiple command components here could be interpreted as "run these components in this order, to completion". This, of course, raises the question of the failure behavior.
• to @fibonacci1729's point, selecting one component (rather than ordering the execution) could also be useful to avoid duplicating variables. This would be useful in particular when combined with the shim executor (and being able to choose the command component to run based on the "command" field in the pod spec).