You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the caller can set stdout and stderr streams in the Operation, which allows the caller to control whether output is written, whether it's written to stdout/stderr, and to capture the output. It does not allow logging from SetConfig. There are not enough tests to ensure that the logging is consistently done only to the Operation streams.
Some possible approaches:
Use the same logging library in both the caller and cnab-go; for libraries with shared global settings, this would allow the caller to control the verbosity and make the logging more reliable (using a logging library is more obvious than digging up a stream from an object to write to), but doesn't distinguish container vs driver logs or necessarily allow the caller to capture all output.
Construct each driver with a logging object (streams or whatever); this could be similar to how logging works for the main function today, but the object with the streams needs to be introduced earlier, so that SetConfg can use it too. Because this would be a custom-for-drivers object, we could include separate streams for before the container runs, the output of the container, and after the container runs (to support the most basic form of interleaving logs when showing them to the user).
CLIs that use cnab-go should be able to:
SetConfig
should be able to write logs, too)This is related to:
SetConfig
(Add Docker driver config to keep container around #139 (comment))Currently, the caller can set
stdout
andstderr
streams in theOperation
, which allows the caller to control whether output is written, whether it's written to stdout/stderr, and to capture the output. It does not allow logging fromSetConfig
. There are not enough tests to ensure that the logging is consistently done only to the Operation streams.Some possible approaches:
SetConfg
can use it too. Because this would be a custom-for-drivers object, we could include separate streams for before the container runs, the output of the container, and after the container runs (to support the most basic form of interleaving logs when showing them to the user).cc @youreddy @silvin-lubecki
The text was updated successfully, but these errors were encountered: