Progress messages may be generated by both the actions framework and action implementations. As a consequence, any non-progress data (i.e. actual action output) to be written to stdout/stderr needs to be delayed until after the the action has completed, as otherwise that output would interfere with progress messages (i.e., progress framework tries to clear any previous progress message, but instead clears actual command output).
This requires any final output to be written to stdout/stderr to be cached in memory until action termination, which could potentially result in out of memory errors if there's a lot of data to be written. For example, there has been a request to output all unique issue instance id's and some related data for an entire, large SSC instance.
Another consequence is that if we ever want pipeline-style actions that simply run a set of fcli and other commands, like 'package->submit scan request->wait for completion->export vulnerability data', the (full) output of these commands cannot be shown until after the action has completed.
As such, we need to provide functionality to allow an action implementation to disable progress messages, for example:
Explicitly through a disableProgressMessages boolean property
Explicitly through a more versatile property that allows for specifying how /where progress messages should be written
Implicitly through an action type or similar property, for example disabling progress messages for type: pipeline
Implicitly based on action instructions, for example if there are any write instructions that write to stdout or stderr
A potential complication is that actions may run other fcli commands that generate progress messages, in particular once we add support for pipeline-style actions. So, if we disable progress messages on the top-level action, we should likely also disable progress messages on fcli commands invoked from that action. Of course, the top-level action could explicitly pass the --progress option on any sub-actions, or alternatively we could maybe automatically set an appropriate value for this option.
Progress messages may be generated by both the actions framework and action implementations. As a consequence, any non-progress data (i.e. actual action output) to be written to stdout/stderr needs to be delayed until after the the action has completed, as otherwise that output would interfere with progress messages (i.e., progress framework tries to clear any previous progress message, but instead clears actual command output).
This requires any final output to be written to stdout/stderr to be cached in memory until action termination, which could potentially result in out of memory errors if there's a lot of data to be written. For example, there has been a request to output all unique issue instance id's and some related data for an entire, large SSC instance.
Another consequence is that if we ever want pipeline-style actions that simply run a set of fcli and other commands, like 'package->submit scan request->wait for completion->export vulnerability data', the (full) output of these commands cannot be shown until after the action has completed.
As such, we need to provide functionality to allow an action implementation to disable progress messages, for example:
disableProgressMessagesboolean propertytypeor similar property, for example disabling progress messages fortype: pipelinewriteinstructions that write tostdoutorstderrA potential complication is that actions may run other fcli commands that generate progress messages, in particular once we add support for pipeline-style actions. So, if we disable progress messages on the top-level action, we should likely also disable progress messages on fcli commands invoked from that action. Of course, the top-level action could explicitly pass the
--progressoption on any sub-actions, or alternatively we could maybe automatically set an appropriate value for this option.