Logrus buffer issue #1511
Logrus buffer issue #1511
Conversation
| @@ -178,7 +178,7 @@ func readCfServiceKey(config abapEnvironmentPullGitRepoOptions, c execRunner) (s | |||
|
|
|||
| var abapServiceKey serviceKey | |||
|
|
|||
| c.Stderr(log.Entry().Writer()) | |||
| c.Stderr(log.Writer()) | |||
There was a problem hiding this comment.
@stippi2 would it make sense to provide a convenience method as part of command.go like c.StderrToLog() and similarly c.StdoutToLog(). I know it potentially spoils the interface but could reduce the risk of someone falling into using log.Entry().Writer(). What do you think?
There was a problem hiding this comment.
This is what auto-completion currently gives:
... but of course you would have to know to look in log in the first place. I think your proposal makes sense, but what do you think about providing a function returning a command instance, which is already fully configured instead (or in addition)?
There was a problem hiding this comment.
@stippi2 good to see that auto-completion proposes the right things;-). Up to now we do already pre-configure the redirect as part of the construction of command.
The methods would more be for scenarios were i.e. Stdout needs temporary redirection perhaps to capture command output and then afterwards reset it and send it back to the logger.
I'd also be fine to do it in an agile manner, continue as is and optimize based on future demand. Still fairly easy to extend and change that later on.
There was a problem hiding this comment.
command.go like c.StderrToLog() and similarly c.StdoutToLog(). I know it potentially spoils the interface
I personally would prefer not keep the interfaces small. In case somebody would like to use another writer etc ... it can simply be provide at c.stderr(MY_WRITER). Less benefit added IMO with additional methods ...
|
/it |
|
/it |
…uffer-issue # Conflicts: # pkg/log/log.go
|
/it |
|
/it |
Changes
Provides work-around for #1474
This avoids the problem of writing chunks larger than 64K that contain no linebreaks. Note that this is not a general solution, as it only solves re-directing tool output to the logging framework. Logrus doesn't provide any facility to override the scanning function. Also it doesn't prevent someone from using log.Entry().Writer(). I am open to other ideas.