compose: Problem using ignore-pull-failures

Description of the issue

There is an issue in the current docker-compose version (1.25.1) when using --ignore-pull-failures. The version 1.25.0 works as expected.

Context information (for bug reports)

Output of docker-compose version

docker-compose version 1.25.1, build a82fef0

Output of docker version

Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a
 Built:             Tue Aug 21 17:24:51 2018
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a
  Built:            Tue Aug 21 17:23:15 2018
  OS/Arch:          linux/amd64
  Experimental:     false

Output of docker-compose config (Make sure to add the relevant -f and other flags)

services:
  consul:
    depends_on:
    - mongo
    - rabbit-puppet-portal
    healthcheck:
      interval: 5s
      retries: 30
      test:
      - CMD
      - curl -f localhost:8500/v1/catalog/nodes
      timeout: 3s
    image: consul:1.2.1
    logging:
      driver: json-file
    volumes:
    - /home/anon/workspace/something-persistence-service/smoke/consul:/consul/config:rw
  mongo:
    environment:
      MONGO_INITDB_ROOT_PASSWORD: test
      MONGO_INITDB_ROOT_USERNAME: test
    healthcheck:
      test:
      - CMD
      - echo 'db.runCommand("ping").ok' | mongo localhost:27017/test --quiet
    image: mongo:4.1.11-bionic
    logging:
      driver: json-file
  rabbit-puppet-portal:
    environment:
      RABBITMQ_DEFAULT_PASS: admin
      RABBITMQ_DEFAULT_USER: admin
      RABBITMQ_DEFAULT_VHOST: portal
    healthcheck:
      interval: 5s
      retries: 5
      test:
      - CMD
      - rabbitmqctl
      - status
      timeout: 5s
    image: rabbitmq:3.7
  something-persistence-service:
    depends_on:
    - consul
    - mongo
    - rabbit-puppet-portal
    environment:
      HOST_IP: consul
      MONGODB_AUTH: "true"
      MONGODB_DATABASE: admin
      MONGODB_PASSWORD: test
      MONGODB_RS_NAME: none
      MONGODB_USERNAME: test
      RABBIT_PORTAL_PASSWORD: admin
      RABBIT_PORTAL_USERNAME: admin
      RABBIT_PORTAL_VIRTUALHOST: portal
    healthcheck:
      test:
      - CMD
      - curl -f http://localhost:11030/somethingpersistenceservice/v1/intern/health
    image: something-persistence-service:dev
    logging:
      driver: json-file
    ports:
    - 0:11030/tcp
    volumes:
    - /home/anon/workspace/something-persistence-service/build/service-logs:/anon/something-persistence-service/logs:rw
version: '3.0'

Steps to reproduce the issue

  1. Create a docker-compose file with a local image that does not exist inside a shared docker registry. Here it is something-persistence-service
  2. Execute docker-compose pull --ignore-pull-failures

Observed result

The command will exit with code 1

docker-compose pull --ignore-pull-failures
Pulling mongo                         ... done
Pulling rabbit-puppet-portal          ... done
Pulling consul                        ... done
Pulling something-persistence-service ... error

Expected result

The command will exit with code 0

docker-compose pull --ignore-pull-failures
Pulling mongo                         ... done
Pulling rabbit-puppet-portal          ... done
Pulling consul                        ... done
Pulling something-persistence-service ... done

Additional information

No LSB modules are available.
Distributor ID: Ubuntu
Description:  Ubuntu 18.04.3 LTS
Release:  18.04
Codename: bionic

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 22
  • Comments: 19

Commits related to this issue

Most upvoted comments

Still happening with 1.26.0. We are stuck with 1.25.0 because of this bug. Any plan for solving this?

This is a significant bug for anyone who is scripting with docker-compose pull --ignore-pull-failures.

That makes me sad πŸ‘Ž

Just saw related MR https://github.com/docker/compose/pull/7134, hopefully it will be the reason for this issue to be closed πŸ˜ƒ

If this is expected behavior then we at least have a semantic versioning failure and 1.25.1 should have been 1.26?

/reopen

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Docker Compose 2.0 was released a few weeks ago, and it solved the problem for me. I can use this option again, and it is nice!

root cause is we neglected in previous fix that --no-parallel isn’t the default pull behaviour, and buid_vs_image fix need to be applied in two places.