Compose "build.network" config does not incorporate project name

[gtfortytwo]

I'm super-grateful for the addition of custom network references to the "build" command in #4095 / #4997 , but is problematically inconsistent with other Compose network configs. The build.network value is interpreted as the fully-qualified name, whereas in all other compose network references a context-local, logical name is used and the "project name" is automatically pre-pended to get the actual network name. For example, let's assume we have the following docker-compose.yml in a project directory called sample:

networks:
  foo:

services:
  my-service:
    build: ./my-service
      network: foo
    image: my-service
    networks:
      - foo

The local name foo is specified as the network to create, to attach at run-time, and to attach at build-time. Compose takes the "project name" of "sample" (derived from the containing directory name, can be overridden via cmdline or envvar) and combines it with the specified network name (in the format [project-name]_[network-name]) to create a custom network called "sample_foo". Similarly, the my-service service attaches to that network by specifying the local name "foo" in services.my-service.networks list - Compose prefixes the project name just as it did when creating the network. However, if one similarly uses the local name "foo" for the build.network config it will fail with the message: "Service 'my-service' failed to build: No such network: foo". If one uses the fully-qualified name "sample_foo" for the build.network config then the build succeeds as expected.

This inconsistency is confusing at best, and really just seems broken to me. The only justification I can think of would be to allow access to a non-compose-local network (such as the default "bridge" network), but that can already be accomplished by using the "pre-existing network" support, just as any compose-declared container/service would.

As a side note, the new build.network and build.target attributes are mentioned in the v3.4 change log, but they are not documented at all on the v3 Compose File Reference page (as of 2017-12-06).

Environment:
  engine: Docker version 17.09.0-ce, build afdb6d4
  compose:  docker-compose version 1.17.0, build ac53b73

[shin-]

Thank you for your comments - however, this is the intended behavior. The networks declared in the Compose file are intended to be used at runtime. Compose doesn't manage build-time resources, as build management in general is out of scope for the project.

As a side note, the new build.network and build.target attributes are mentioned in the v3.4 change log, but they are not documented at all on the v3 Compose File Reference page (as of 2017-12-06).

Please report docs issues on the docs repo!

[Fi1osof]

Hello from y2k20

[Fi1osof]

@gfortytwo, my solution:

networks:
  default:
    name: foo

services:
  my-service:
    build: ./my-service
      network: foo
    image: my-service

Will created default network "$project_name_$network_name" with name "foo" and will finded for build.network.

[mattiasb]

@Fi1osof that network will not necessarily be up at build time though.

I'm scratching my head here on how to make docker-compose build use the same network as the running containers. The best I've come up with is to do like you suggest and add a note in the readme that they need to run docker-compose run true before building so that the network is up before hand.

I mean. I understand the motivation personally. But trying to explain it to my co-workers that don't care about docker more than the syntax of Dockerfile and how to run docker-compose <build|run|push>.

Maybe my underlying issue is a bug though that I'm just trying to work myself around. We're experiencing DNS issues with the default bridge network that works fine in the network that docker-compose creates. If we only could build in that network all would be dandy. But yeah, maybe fixing the root issue is the correct way to go?