[RFC] deprecate push --ignore-push-failures and implement --skip-missing or --ignore-missing
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 38.2k
- Forks
- 5.8k
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 55
Description
Is your feature request related to a problem? Please describe.
See
- my observation in https://github.com/docker/compose/pull/7430#discussion_r420606842
- original implementation: https://github.com/docker/compose/pull/3595
The docker-compose push subcommand has an --ignore-push-failures option, which ignores any error that occurs when pushing (one of) the images built in the docker-compose.yaml file.
This flag can be useful for situations where multiple services define a build:, but (possibly) not all of those images have been build (and are thus missing in the local image cache).
However, currently any error that occurs is ignored. I think this is bad behavior, as this may be hiding important failures (e.g., trying to push when I was not authenticated, trying to push but the registry is not reachable, or perhaps there's a failiure on the registry side).
Here's an example:
docker-compose file:
version: "3.7"
services:
missing:
build:
context: .
dockerfile: Dockerfile.example
image: localhost:5000/foobar:missing
built:
build:
context: .
dockerfile: Dockerfile.example
image: localhost:5000/foobar:built
unreachable:
build:
context: .
dockerfile: Dockerfile.example
image: no-such-registry.example.com:5000/foobar:unreachable
unauthenticated:
build:
context: .
dockerfile: Dockerfile.example
image: docker.io/library/foobar:unauthenticated
Dockerfile.example
FROM busybox
RUN echo "foo" > /foo
Build images for the built, unreachable, and unauthenticated services:
docker-compose build built unreachable unauthenticated
Start a local registry, and push the images with docker-compose push --ignore-push-failures:
docker run -d --name registry -p 127.0.0.1:5000:5000 registry:2
docker-compose push --ignore-push-failures
Pushing missing (localhost:5000/foobar:missing)...
The push refers to repository [localhost:5000/foobar]
ERROR: tag does not exist: localhost:5000/foobar:missing
Pushing built (localhost:5000/foobar:built)...
The push refers to repository [localhost:5000/foobar]
554895133718: Pushed
5b0d2d635df8: Pushed
built: digest: sha256:2505d8793b4cfe865315715960a4e7eb2fa683f3cafaa7198a0303d9504022a6 size: 734
Pushing unreachable (no-such-registry.example.com:5000/foobar:unreachable)...
The push refers to repository [no-such-registry.example.com:5000/foobar]
ERROR: Get https://no-such-registry.example.com:5000/v2/: Service Unavailable
Pushing unauthenticated (docker.io/library/foobar:unauthenticated)...
The push refers to repository [docker.io/library/foobar]
554895133718: Preparing
5b0d2d635df8: Preparing
ERROR: denied: requested access to the resource is denied
Check the exit-code and see that the command exited succesfully:
echo $?
0
Describe the solution you'd like
I think we should deprecated the existing flag, and replace it with a --skip-missing or --ignore-missing flag;
- Without the flag set,
docker-compose pushwill fail on any failure that occurs when pushing - If the flag is set, docker compose will check if the image exists locally, and if not, skip pushing of the image
- When skipping an image, it prints an
INFOmessage, informing the user that no local image existed, and that pushing was skipped
- When skipping an image, it prints an
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the docker-compose push subcommand and reproduce the example using Dockerfile.example, the local registry, and the listed push commands. Done means the existing flag is deprecated, missing local images can be skipped with the replacement flag and an INFO message, while authentication, connectivity, and registry failures still cause push to fail.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, docker-compose, go
- Domain
- cli
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100