Open thaJeztah opened 4 days ago
@thaJeztah do you think we should omit the help
output as well? So that no error is printed in the case of context.Cancelled?
We wrap the error for run
with the withHelp
function.
https://github.com/docker/cli/blob/master/cli/command/container/run.go#L299
Regarding status codes, 125 is the default for the toStatusError
function which is only run sometimes depending on the code path used inside the runContainer
function https://github.com/docker/cli/blob/master/cli/command/container/run.go#L311
do you think we should omit the help output as well? So that no error is printed in the case of context.Cancelled?
I'm leaning towards "yes" there; assuming we know that context.Cancelled would always be triggered by a user-action (canceling the CLI). The --help
output was meant for cases where a user used the CLI incorrectly (e.g. invalid / unknown flag etc), which isn't the case here.
Not sure if we can also run into context timeout cases (which may still be something we should print?), or if this means we could use the helper utility that's in errdefs
; https://github.com/docker/cli/blob/5afa739692fbf3c96f063d3f822f27f48dad3f6a/vendor/github.com/docker/docker/errdefs/is.go#L120-L123
Description
Noticed this on docker 27.4.0-rc.3; when canceling the CLI, we print the
context canceled
message; this is unlikely informative to the user, and we might as wellI also noticed that the exit-code is non-zero in these situations, but I'm not sure what the correct thing to do is there. For example,
tail
also exits with a non-zero exit-code, although it uses a specific code for it (130);