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
Use case:
I'm implementing a wait-for-logs strategy to determine container readiness.
I could do polling and repeatedly call logs at some interval, but this is inefficient as I end up re-processing log lines.
I would prefer to add a stream data listener and check each log line as it output.
With the current implementation of logs (and the call to execCompose), it doesn't resolve until the process exits (which will be never for long running services like mysql).
I'd like to propose that instead of calling logs with an option to turn on follow and be given an un-resolving promise, we call a logstream method that resolves to an object containing {stdout, stderr, process}. This way we can attach listeners to the streams and potentially close the process when we're done w/ the logs.
Would a PR with this functionality be welcome?
The text was updated successfully, but these errors were encountered:
Use case:
I'm implementing a wait-for-logs strategy to determine container readiness.
I could do polling and repeatedly call logs at some interval, but this is inefficient as I end up re-processing log lines.
I would prefer to add a stream data listener and check each log line as it output.
With the current implementation of logs (and the call to execCompose), it doesn't resolve until the process exits (which will be never for long running services like mysql).
I'd like to propose that instead of calling
logs
with an option to turn on follow and be given an un-resolving promise, we call alogstream
method that resolves to an object containing{stdout, stderr, process}
. This way we can attach listeners to the streams and potentially close the process when we're done w/ the logs.Would a PR with this functionality be welcome?
The text was updated successfully, but these errors were encountered: