Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUG: docker-compose build still ignores service-order from yaml and depends_on #9584

Closed
typoworx-de opened this issue Jun 22, 2022 · 1 comment

Comments

@typoworx-de
Copy link

docker-compose build still ignores services key-order from yaml and depends_on.

dummy docker-compose.yml to explain the problem:

version: '3.5'

services:
  first-service:
    image: my-first-service
    build:
      context: .
      dockerfile: Dockerfile.my-first-service

  # build depends on my-first-service using f.e. COPY --from=my-first-service
  second-service:
    image: my-second-service
    depends_on:
      - first-service
    build:
      context: .
      dockerfile: Dockerfile.my-second-service

Running now docker-compose build will start building. But for some reason sometimes the build doesn't start (depending on service-names?!) with the first key -- which is here "first-service", but instead starts in different order. Starting with "second-service" build will break the whole build.

I've checked this on a practice example for a custom-build and the only work-around on this is to run:

docker-compose build first-service
docker-compose build second-service

Or for automation the hack for a docker-compose.sh could be:

#!/bin/bash

echo "Determining build-order for docker-compse services ..."
services=$(yq '.services|keys' docker-compose.yaml)

for service in ${services}; do
  docker-compose build ${service} ${@}
done

The mentioned two work-arounds work for my build, but using regular docker-compose build will make it stuck!

I think this still is a bug.

@milas
Copy link
Contributor

milas commented Jun 22, 2022

Thanks for the report! I'm closing this as a duplicate of #9232 and #8538, but if I missed something and you believe this is a different case, please let me know and I will look at re-opening.

@milas milas closed this as not planned Won't fix, can't repro, duplicate, stale Jun 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants