cli: [Proposal] docker pull return code
This is a follow up to https://github.com/moby/moby/issues/27658 //cc @neilhwatson @KristofErr @DenerKup @gregmartyn
It seems like docker pull
returning different exit codes would be helpful for automating failures.
For example, to distinguish between image name doesn’t exist and registry is wrong.
About this issue
- Original URL
- State: open
- Created 7 years ago
- Reactions: 22
- Comments: 19 (2 by maintainers)
Commits related to this issue
- docker-common: fix ceph_health check usage of `docker ps` is not good since `docker ps` will always return `0` (see: https://github.com/docker/cli/issues/538). Signed-off-by: Guillaume Abrioux <gabr... — committed to ceph/ceph-ansible by guits 7 years ago
- docker-common: fix ceph_health check usage of `docker ps` is not good since `docker ps` will always return `0` (see: https://github.com/docker/cli/issues/538). Signed-off-by: Guillaume Abrioux <gabr... — committed to ceph/ceph-ansible by guits 7 years ago
- docker-common: fix ceph_health check usage of `docker ps` is not good since `docker ps` will always return `0` (see: https://github.com/docker/cli/issues/538). Signed-off-by: Guillaume Abrioux <gabr... — committed to ceph/ceph-ansible by guits 7 years ago
- docker-common: fix ceph_health check `docker ps` will always return `0` (see: https://github.com/docker/cli/issues/538). Signed-off-by: Guillaume Abrioux <gabrioux@redhat.com> — committed to ceph/ceph-ansible by guits 7 years ago
- docker-common: fix ceph_health check `docker ps` will always return `0` (see: https://github.com/docker/cli/issues/538). Signed-off-by: Guillaume Abrioux <gabrioux@redhat.com> — committed to ceph/ceph-ansible by guits 7 years ago
- docker-common: fix ceph_health check `docker ps` will always return `0` (see: https://github.com/docker/cli/issues/538). Signed-off-by: Guillaume Abrioux <gabrioux@redhat.com> — committed to ceph/ceph-ansible by guits 7 years ago
- docker-common: fix ceph_health check `docker ps` will always return `0` (see: https://github.com/docker/cli/issues/538). Signed-off-by: Guillaume Abrioux <gabrioux@redhat.com> — committed to ceph/ceph-ansible by guits 7 years ago
This would be useful when automating
docker pull
; it would be possible to detect if an image for a running service has been updated, and only restart the service if the image has been updatedI see a couple of different cases here:
I’d like to distinguish between 2 and 3 (or at least have the option to distinguish between them), so that I know whether I have to restart the running containers or not.
I think this could be useful not only for
docker pull
command. I’m facing the same ‘issue’ withdocker ps
command.for instance:
in that case, it could be cool to have
docker ps
command returning something different than0
if there is no match with what has been filtered.Bash is a perfectly viable language for certain situations. No need for a cannon (APIs) when an exit code can do just fine.
@rubdos Distinguishing between (2) and (3) by non-zero exit code would be detrimental for CI systems that interpret non-zero codes as failure. If (2) or (3) were to exit with non-zero status, it would require all developers to call
docker pull || true
. And this would mask real errors, e.g. (1). Totally wrong. In general, non-zero exit statuses mean failure - and in both cases (2) and (3) exit status zero should be returned.If your goal is to “watch” for new image versions, you should use API to check for changes.
In the CLI world I think folks expect searches to function like grep which returns none zero when no match is found.
NO. Parsing natural language output is criminally wrong, if only because English is not the only natural language in existence, and software gets localized.
@guits When something returns empty list because there are no elements or nothing matches filters it looks more like a program success neither than failure. So it is controversial issue. Maybe its better to create a separate thread for this.
Ack. Maybe
docker pull
could have an option that sets status codes for (2) and (3). I feel like there’s still people that want it.Fair point, although
docker pull [image] --extended-exit-codes
would feel like a very cheap way to avoid calling APIs.@rulatir I was merely suggesting a workaround until docker fixes this blatant issue. It’s asinine that the product development team didn’t think this through during initial development. I’m sure a lot of us spend a lot of time writing and documenting hacks for poorly (yes, poorly) implemented systems, including but not limited to Docker’s
pull
command. As for the hack/workaround that your dismissing with an terse remark, let me explain it for you: write the work around in the localized language of the system, don’t change the language for the automated process, document the hack, write tests for it for pre-upgrade CI processes, and review the need for the hack annually. Hopefully docker will fix this issue by your first review.@thaJeztah is correct, returning non-zero will not be a realistic option without explicitly requesting the ad. @gregmartyn I agree that a solution like
--extended-exit-codes
is better option. Extending on that, a bitwise system would be desirable to pull multiple statuses from the same exit code.Other solutions that I’ve slapped together relied on the command being able to dump a status to in a parse-able format. For example, you might add a more verbose status message that can be redirected to a json file, such as
outToJson=/tmp/docker_pull.json
. If the process exits0
, you would know that the command ran successfully and you could go check the status in the json file. The json files would have to have status codes and more advanced status tracing to allow even the most complex status be processes via CI and handled. Just throwing another non-language option into the mix without changing exit codes and allowing for complex scenarios.What about
--extended-exit-codes
as suggested above?@VertigoRay that approach does work, for now at least; I don’t like having to depend on magic strings though 😞
Returning non-zero status codes for “success” cases will break many things, and will not be a realistic option.