@keboo correctly questioned the behavior or the NotRun method of PipelineResult which did nothing.
In the current design, this method could be removed (it is currently called from CliSubstem) or could reset the default values. Doing nothing is wrong.
However, it appears to point to a deeper issue. Multiple subsystems will be called, and we should track these in a thoughtful way.
Initial thoughts:
Should we track calling "normal pipeline subsystems" such as validation
We currently allow subsystems to run even if the result is already handled (already handled, should be a different terminating subsystem). This design may be important for cleanup, but should we have an absolute restriction to exactly one terminating subsystem. If this is not the decision, the PipelineResult needs to be changed. (Note CheckIfActivated blocks running unneeded subsystems, so it is a niche case if more than one is needed)
If we have exactly one terminating subsystem, we may want the current design plus a list of subsystems that run. If we allow multiple terminating subsystems, then we probably want a list of all subsystems.
@keboo correctly questioned the behavior or the
NotRunmethod ofPipelineResultwhich did nothing.In the current design, this method could be removed (it is currently called from
CliSubstem) or could reset the default values. Doing nothing is wrong.However, it appears to point to a deeper issue. Multiple subsystems will be called, and we should track these in a thoughtful way.
Initial thoughts:
PipelineResultneeds to be changed. (NoteCheckIfActivatedblocks running unneeded subsystems, so it is a niche case if more than one is needed)If we have exactly one terminating subsystem, we may want the current design plus a list of subsystems that run. If we allow multiple terminating subsystems, then we probably want a list of all subsystems.