Compose: Problem using ignore-pull-failures

Created on 7 Jan 2020 · 9Comments · Source: docker/compose

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

Create a docker-compose file with a local image that does not exist inside a shared docker registry. Here it is something-persistence-service
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

kinbug

Source

core23

👍15

Most helpful comment

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

PierreBeucher on 9 Jun 2020

👍5

All 9 comments

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

bramswenson on 8 Jan 2020

👍3

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

bramswenson on 8 Jan 2020

👍2

This probably is a side effect of https://github.com/docker/compose/pull/7052 and all the confusion within Build vs Image (https://github.com/docker/compose/issues/6464)
Clearly unexpected.

ndeloof on 9 Jan 2020

Please note that, if the image you refer to in your compose file that is not available on a registry do declare a build section, then compose 1.25.1 will not fail but let you know this one should be built :

➜ docker-compose pull 
Pulling mongo                         ... done
Pulling rabbit-puppet-portal          ... done
Pulling consul                        ... done
Pulling something-persistence-service ... done
WARNING: Some service image(s) must be built from source by running:
    docker-compose build something-persistence-service

(exit with code 0)

This behaviour is sane imho, as without this build definition, compose model is incomplete, and docker-compose would need to assume image is built by another service it can't control. For sure you can consider you're in charge for this, but I don't see any reason _not_ to tell compose how to build (or rebuild) this image

wdyt ?

ndeloof on 9 Jan 2020

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.

ndeloof on 9 Jan 2020

👍1

That makes me sad :-1: