Allow some commands to run without full config validation

[dnephin]

This has come up a couple times in the last week (most recently in #1972).

Commands like stop, kill, ps, logs, port, restart, rm, start only need to know the list of service names, not any part of the service definition.

Commands like build, pull only need to care about one or two fields from the service definition (build and dockerfile for build, image for pull).

If we could split our config validation into two phases (a top level service name validation, and a full validation) we could support that first group of commands.

The second group would be more work, and require a three phase validation.

[ChrisRut]

+1

[ebmeierj]

👍

[peterwhitesell]

+1

[broneq]

+1

[mattjohnson]

+1

[dionmcm]

+1

Any progress on this?

[Chexpir]

+1

[stale]

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.

[stale]

This issue has been automatically closed because it had not recent activity during the stale period.

[CafeLungo]

Still need this, I believe. I just ran into down trying to validate build paths. We deploy with up --no-build, but cannot down the same images without the respective docker build paths present.

$ docker-compose -f docker-compose.yml down --volumes --rmi local
ERROR: build path /home/user/modules/app either does not exist, is not accessible, or is not a valid URL

Resorting to docker down commands as a workaround.

[mustard123]

Still need this, I believe. I just ran into down trying to validate build paths. We deploy with up --no-build, but cannot down the same images without the respective docker build paths present.

$ docker-compose -f docker-compose.yml down --volumes --rmi local
ERROR: build path /home/user/modules/app either does not exist, is not accessible, or is not a valid URL

Resorting to docker down commands as a workaround.

yup having the same issue

[paslandau]

I believe this issue is still valid and should be re-opened. I just ran into this problem due to the dual nature of docker compose to be used for building as well as running containers. In my case, I defined an env_file in a docker-compose.yml config file that does not exist during build time and makes the command fail - even though it is not needed for build at all. Error is:

open /path/to/compose-secrets.env: The system cannot find the file specified.

[KostaGorod]

this issue is still valid,
can't pull docker during deployment with missing required env file

• Fails with an error (missing file):

   env_file:
      - path: .myservice.env
        required:  true

• Succeeds without error (missing file ignored):

   env_file:
      - path: .myservice.env
        required:  false

the expected behavior is to pull without the required env_file, which is required only for running the service itself..