Docker
85 verified issues
key sequence to detach from `docker-compose up`
this has been topic in #291, however i want to make aware of this feature request a little more . i vote for a key-sequence that you can use to detach from `docker-compose up` without stopping all containers (i.e. when you forgot to pass `-d`). There seems to be a key-sequence for attached docker-containers (`Ctrl-p` `Ctrl-c`). It seems plausible to reuse this in docker-compose.
Is there a way to delay container startup to support dependant services with a longer startup time
I have a MySQL container that takes a little time to start up as it needs to import data. I have an Alfresco container that depends upon the MySQL container. At the moment, when I use fig, the Alfresco service inside the Alfresco container fails when it attempts to connect to the MySQL container... ostensibly because the MySQL service is not yet listening. Is there a way to handle this kind of issue in Fig?
Define services which are not started by default
Users quite often define maintenance scripts, test suites, debugging systems in their Compose files which they don't want to run when they do `docker-compose up`. There should be some way of defining what services are started by default, but can be still be run manually by doing `docker-compose up servicename` or `docker-compose run servicename ...`. Possible solutions 1) Recommend users to use a separate Compose file 2) Add an option to services to make them not start by default 3) Add a top-level configuration option to define the default services 4) Add a concept of a thing like a service, but is just for one-off commands ("scripts", "tasks", etc...) (Please suggest others if you have ideas.) Data points: - https://github.com/docker/compose/issues/697 - https://github.com/docker/compose/issues/912 - https://github.com/docker/compose/issues/942 - https://github.com/docker/compose/issues/1439 - https://github.com/docker/compose/issues/1547 - #542 - "test" service in https://github.com/heroku/logplex/blob/master/docker-compose.yml - ~~@cpuguy83: "I've got a little helper service in my compose yaml that injects a bunch of stuff into redis for hipache, which of course exits when it is done. Can't use `compose up` w/o the `-d`"~~ this is fixed now that we don't exit from `compose up` until all services have exited.
Support for NVIDIA GPUs under Docker Compose
Under Docker 19.03.0 Beta 2, support for NVIDIA GPU has been introduced in the form of new CLI API --gpus. https://github.com/docker/cli/pull/1714 talk about this enablement. Now one can simply pass --gpus option for GPU-accelerated Docker based application. [code block] As of today, Compose doesn't support this. This is a feature request for enabling Compose to support for NVIDIA GPU.
docker-compose copy file or directory to container
we miss a possibility to copy a file or directory using docker-compose. I find this really useful. Please check many +1 in premature closed https://github.com/docker/compose/issues/2105
Feature: Ability to clear log history
A feature I've thought would be useful since originally using Fig, and now Compose would be the ability to clear the log history for Composed-managed containers. Long-running or "chatty" containers can end up with a lot of log noise that may not be wanted. I'd expect a command like the following would solve the problem: `$ docker-compose logs --clear [service]`
Execute a command after run
Hi, It will be very helpful to have something like "onrun" in the YAML to be able to run commands after the run. Similar to https://github.com/docker/docker/issues/8860 [code block] After the mongodb start, It will dump db2dump.domain.lan and restore it. When I will stop and then start the container, onrun part will no be executed to preserve idempotency. EDIT 15 June 2020 5 years later, Compose wan't to "standardize" specifications, please check https://github.com/compose-spec/compose-spec/issues/84
docker-compose slow on docker for mac os beta
docker-compose is slow with docker for mac os beta on my home network. Here is my workaround for now: - docker-compose up (take ages) - shut down wifi - docker-compose up (really fast) - re-enable wifi I do not reproduce the issue on another network than mine, my work network for instance do not make it slow. I already had a potentially related issue with the docker client itself which couldn't pull any image (going to bizarre local ips instead of the docker hub registry) but it has been fixed since one of the latest docker for mac os beta update. The issue is not reproduced against the docker-toolbox, only the "native" docker for mac. My version of docker-compose is : `docker-compose version 1.7.0, build 0d7bf73` My version of docker for mac is: `Version 1.11.1-beta10 (build: 6662)` The docker-compose file I'm trying to run is: [code block]
allow removing something in docker-compose.override.yml
My usecase is that the base `docker-compose.yml` maps a certain port in the `ports` section. In my `docker-compose.override.yml` I'd like to change that port since I already have a different service running there on my host. As far as I understand the current implementation it is only possible to add stuff, override extends the other file. As far as I can tell there is no way to remove an entry. And I can't think of an obvious syntax for it.
Docker-compose up failing because "port is already allocated"
My docker container is able to successfully build but when I enter the command docker-compose build, the following error is returned: Starting docker_etl_1 ... Starting 1e5f56853e10_1e5f56853e10_1e5f56853e10_docker_postgis_1 ... Starting 1e5f56853e10_1e5f56853e10_1e5f56853e10_docker_postgis_1 Starting 1e5f56853e10_1e5f56853e10_1e5f56853e10_docker_postgis_1 ... error ERROR: for 1e5f56853e10_1e5f56853e10_1e5f56853e10_docker_postgis_1 Cannot start service postgis: driver failed programming external connectivity on endpoint 1e5f56853e10_1e5f56853e10_1e5f56853e10_docker_postgis_1 (91464afbee8bf7212061797ec0f4c017a56cc3c30c9bdaf513127a6e6a4a5a52): Error starting userland prStarting docker_etl_1 ... done ERROR: for postgis Cannot start service postgis: driver failed programming external connectivity on endpoint 1e5f56853e10_1e5f56853e10_1e5f56853e10_docker_postgis_1 (91464afbee8bf7212061797ec0f4c017a56cc3c30c9bdaf513127a6e6a4a5a52): Error starting userland proxy: Bind for 0.0.0.0:5432 failed: port is already allocated Here is my docker-compose.yaml version: '2' services: postgis: build: ./postgis volumes: - ../src/main/sql:/sql ports: - "5432:5432" etl: build: ./etl volumes: - ..:/national-voter-file entrypoint: - python3 - /national-voter-file/load/loader.py and here is the Dockerfile: FROM m
Using shell command in docker-compose.yml
Hello, is there a way to use shell commands in `docker-compose.yml` file? Here is my use case: [code block] Currently it's giving me this error: [code block]
docker-compose up doesn't pull down latest image if the image exists locally
It would be nice if there were an option to check for new versions of images when running `docker-compose up`. We already have this functionality with `docker build --pull` as was discussed here https://github.com/docker/docker/issues/4238 and there is an open issue to bring `--pull` to `docker run` here https://github.com/docker/docker/issues/13331. I propose adding `--pull` to `up` to always attempt to pull a newer version of the images in the compose file.
docker-compose dry run
Would like insight to what docker-compose generates/executes
docker-compose build --push <registry>
This would be a nice feature for creating and deploying of containers on a different (development) machine than the productive ones (which may run via image: option)
Hooks/ Plugins support to run arbitrary scripts
It would be nice if `docker-compose up|down|..` would look for custom scripts in the current directory, like: [code block] I guess this is mostly helpful when docker-compose is used to run the development environment. These scripts should not be meant to configure containers. My current use-cases include: - set up hostnames in `/etc/hosts` after container startup - run docker-rsync after container started Eventually docker-compose should allow these scripts to run in the background and stream stdout/stderr to `docker-compose logs`. Related https://github.com/docker/compose/pull/74 https://github.com/docker/compose/issues/57
Docker compose pull doesn't respect local images
During my searches I've seen this issue raised and closed a few times, but even using the latest build of docker-compose, this still doesn't behave the way I understand that it is expected to. Scenario: We're building a composed environment for our CI tests to run. We grab a database image, an api image, and a _local_ copy of the image containing application we are trying to test (it has been built in a previous CI step, and tagged with the build hash provided by our CI environment (CIRCLE_SHA1) docker-compose.yml [code block] The commands we run then are as follows: [code block] Actual Result: No matter what I do, docker compose always tries to pull my CIRCLE_SHA1 tagged version from docker hub. it doesn't exist there, I never want to push it (until it passes tests and is re-tagged as :latest and/or :release I have a unique tag CIRCLE_SHA1 which only exists inside the build environment, meaning no confusion for docker-compose when it tries to pull, and yet, it seems to try to fetch it anyway, and fail even though that exact tag exists locally. Expected Result: I'd expect the fact that there is no remote build tagged with CIRCLE_SHA1 to cause docker-compose to use the local copy it finds. I need to do pull, because I want everything else to be the latest. I'd suggest that if there is confusion where `image:` refers to a remote repository, then perhaps we could use `local:` instead, to reference a local image?
The default naming scheme for containers created by Compose
> The default naming scheme for containers created by Compose in this version > has changed from `<project>_<service>_<index>` to > `<project>_<service>_<index>_<slug>` Is there any way to disable this behavior apart from using `container_name` in yaml file? We have many scripts that rely on container names and are not using swarm, just a single container stack. This change is very inconvenient for us.
Provide RPM and DEB packages for compose
Not everyone likes to install binaries (#1288). It might be good to provide a system package for compose. We should use https://github.com/spotify/dh-virtualenv for the debian package and look into a similar approach for the rpm.
docker-compose hangs
Description of the issue In a new server installation (on a VPS provided by OVH) running Ubuntu 18.x the Docker system works flawlessy and fast but docker-compose sometimes hangs indefinitely for no reason. And for every command, from version to ps, up, logs and so on. I tried everything regarding DNS and name resolution, even disabling systemd-resolved. When it works it is fast. When it hangs I can see the `/tmp/_Mxyz123123` directory created. Running with verbose hangs before any output. And then completes flawlessy. Context information (for bug reports) Output of `docker-compose version` [code block] Output of `docker version` [code block] Output of `docker-compose config` (Make sure to add the relevant `-f` and other flags) [code block] Steps to reproduce the issue 1. docker-compose <command> Observed result Sometimes hangs Expected result Run fast. Stacktrace / full error message No stacktrace but i managed to strace the behavior. [code block] Additional information Linux vps[omit] 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux Ubuntu 18.04.2 LTS docker-compose installed with curl I have lot of other docker-compose environments working and this is the first time I see this behavior. Any idea on what to check or where to look?
Allow for existing containers (allow sharing containers across services)
I think it would be useful if compose could allow you to specify containers that may already exist, eg: [code block] If the container 'shareddata' did not exist, it would be created as usual. If, however, that container already existed, the allow_existing: true setting would not complain about a duplicate container, instead just skipping creation (and perhaps it would try to bring the container up if it were stopped?). I haven't python-ed in a long time, but I might be able to create a PR for this feature if someone wanted to give me a little guidance on where the best place to start looking into the code would be.
Docker Compose mounts named volumes as 'root' exclusively
It's about named volumes (so no "data volume container", no "volumes-from") and docker-compose.yml. The goal here is to use docker-compose to manage two services 'appserver' and 'server-postgresql' in two separate containers and use the "volumes:" docker-compose.yml feature to make data from service 'server-postgresql' persistent. The Dockerfile for 'server-postgresql' looks like this: [code block] Adn the docker-compose.yml looks like this: [code block] Then I start everything with `docker-compose up -d`, I enter my server-postgresql container with `docker-compose exec server-postgresql bash`, a quick `ls` does reveal `/volume_data`, I then `cd` into it and try `touch testFile` and got "permission denied. Which is normal because a quick `ls -l` show that `volume_data` is owned by `root:root`. Now what I think is happening is that since I have `USER postgres` in the Dockerfile, when I run `docker-compose exec` I am logged in as user 'postgres' (and the postgresql daemon runs as user 'postgres' as well, so it won't be able to write to `/volume_data`). This is confirmed because when I run this instead: `docker-compose exec --user root server-postgresql bash` and retry to `cd /volume_data` and `touch testFile`, it does work (it's not a permission error between the host and the container, as it is somtimes the case when the container mounts a host folder, this is a typical unix permission error because `/volume_data` is mounted as 'root:root' while user 'postgres' is tryin
Define host volumes in the `volumes` section of the Compose file
It seems that there is not the possibility to mount a host directory using the `volumes` section using the versrion 2 I would propose an configuration example [code block] My use case: docker-compose.yml [code block] Override docker-compose.prod.yml [code block]
[1.7] CTRL+C fails to stop containers when running compose in the foreground
I can't reproduce it but I would say about 10% of the time when I hit CTRL+C, the containers that were started with `docker-compose up` fail to stop. I'll get an ABORT message in the terminal but they are still up. When it works, it says "gracefully stopping..." instead of ABORT. At this point I need to `docker-compose stop` them to "really" stop them. It was much worse in earlier versions of Compose but it's still happening often enough that I feel like it needs some attention. If you need more info let me know. Environment System [code block] Docker [code block] Docker Compose [code block] Potentially relevant information When I encounter the issue I'm always running multiple containers, such as postgres, redis, and multiple web services. I never run 1 container so I can't say for sure if it would happen with only 1. It happens with and without using `links` and both the legacy and v2 `docker-compose.yml` files.
entrypoint defined in docker-compose.yml wipes out CMD defined in Dockerfile
Hi, I am following the example on https://docs.docker.com/compose/startup-order/ to make sure the database is running before I start the application. My `Dockerfile` contains the command [code block] and in my `docker-compose.yml` I have [code block] but after the postgres database starts the service container just exits straight away. [code block] Looking inside the running container I can see the entrypoint does not have the command appended [code block] If both command and entrypoint are in the same place (either in the `Dockerfile` or in the `docker-compose.yml`) the application starts up properly. [code block] Any idea is this is a bug or I am doing something wrong? Thanks
Overriding the set of values when extending the "ports" option.
The default behavior when extending a service or overriding a whole docker-compose.yml file is to concatenate the sets of values on the multi-value options: ports, expose, external_links, dns and dns_search. The problem appears when for example you have two production hosts both serving on the port 80 and a single machine for development, there is no way of extending or overriding the services for a development environment that avoids the port collision on the host. An example: lets assume there are two servers one is a REST API and the other is a webpage that uses the API, both listen on port 80 on the production host - compose.yml on host A: [code block] - compose.yml on host B: [code block] On a development environment where you want to test this setup you would define: - compose.override.yml on dev for A: [code block] - compose.override.yml on dev for B: [code block] Of course the "ports" option is concatenated with the production and there is no way of running both containers on the same host because both try to bind to port 80. Is there any workaround or yml specific syntax for this use case?
Pass variables inside fig.yml on runtime
Is it possible to configure a fig.yml in such way that you can pass on execution time variables instead of hard-wiring them inside the fig.yml? I think a generic variable injection during execution would be quite useful for various use cases. e.g: <pre> jenkins: image: aespinosa/jenkins:latest ports: - "8080" hostname: ${HOSTNAME} </pre> HOSTNAME=ci fig up That could inject the variable HOSTNAME inside the fig.yml during execution and execute a docker run with hostname `ci`. ps. This is different than passing environment variables inside docker which is already supported (http://www.fig.sh/yml.html#environment)
feature: including external docker-compose.yml
The Problem I'd like to use fig for acceptance testing of services In the case of a single service with a single level of dependencies this is easy (ex: a webapp with a database). As soon as the dependency tree grows to depth > 1, it gets more complicated (ex: service-a requires service-b which requires a database). Currently I'd have to specify the service dependency tree in each `fig.yml`. This is not ideal because as the tree grows, we end up with a lot of duplication, and having to update a few different `fig.yml`'s in different projects when a service adds/changes a dependency is not great. Proposed Solution Support an `include` section in the `fig.yml` which contains url/paths to other `fig.yml` files. These files would be included in a `Project` so that the top-level `fig.yaml` can refer to them using `<proejct>_<service>`. Example config [code block]
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed
Got this error on both machines almost at the same time with docker-compose and lately with fig after rollback. A few search results points to python/openssl issue but i simple can't figure out where to dig to. Python/openssl comes from homebrew. Boot2Docker-cli version: v1.4.1 Git commit: 43241cb Client version: 1.4.1 Client API version: 1.16 Go version (client): go1.4 Git commit (client): 5bc2ff8 OS/Arch (client): darwin/amd64 Server version: 1.4.1 Server API version: 1.16 Go version (server): go1.3.3 Git commit (server): 5bc2ff8
[BUG] Regression: array items[0,1] must be unique starting from 2.24.1
Description As per the subject, starting from 2.24.1, I am encountering this issue when there are overrides. Steps To Reproduce Create 2 files: 1. docker-compose.yaml [code block] 1. docker-compose.override.yaml [code block] WIth 2.23.3: [code block] With 2.24.1: [code block] Compose Version [code block] Docker Environment [code block] Anything else? _No response_
Add support for --build-args
As this docker/docker#15182 functionality has been merged, it would be great to manage with Compose I.e.: Dockerfile with default variables [code block] Overriding through docker-composer.yml [code block] Or an hierarchy of extended environments [code block]
Switch to using hyphens as a separator in hostnames
The hostname format used by fig creates names that are not strictly valid. Current pseudo-code: [code block] This generates names like `cluster_hadoop_1`. Underscores are not valid (though in practice _most_ components are tolerant of this). Valid names should match `[a-zA-Z0-9\-]+`. I came across this error when trying to test out some hadoop/hdfs containers and hadoop bailed with an exception saying that `hdfs://flume_hadoop_1/` was not valid URI (even though it was in `/etc/hosts` and `ping flume_hadoop_1` worked just fine). See: http://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_host_names Changing this to dashes is easy, but it would break existing configurations that depend on hard coded container names.
The project name should be configurable
Ideally in `fig.yml` (how do we have general config in there? maybe we need a top level `services` key?), but maybe in a separate `.fig-project` file or something.
`docker-compose up` hangs when tty parameter is true
Here's a minimal setup to reproduce the issue: Dockerfile content: [code block] docker-compose.yml content: [code block] Here's what happens when I try docker-compose up: [code block] My user is added to `docker` group, and the output is the same when run from `sudo`. It manages to attach only with `docker-compose run` command. I tried the experiment with same outcomes on `Docker version 1.9.1, build a34a1d5`, and compose versions `1.4.0`, `1.6.0`, and `1.6.2`. UPD: docker info output: [code block] `docker-compose --verpose up` output: [code block]
Since docker 1.3.0 / fig 1.0.0 volumes are not mounted when fig up'ing existing containers
Since docker 1.3.0 / fig 1.0.0 (I upgraded both at the same time), I cannot fig up my projects without fig rm'ing before. If I do fig up on already existing (stopper) containers, volumes specified in fig.yml aren't remounted (default docker mounts instead, so empty dirs). fig rm && fig up recreates everything correctly but for locally built containers this is pretty time consuming.
[BUG] Building with bake hangs indefinitely
Description Our CI started to hang on deployment somewhen last month, as we're not pinning docker compose. [code block] I've took the liberty to shorten/edit the `args`. I've alse hit `CTRL + C` to abort it, as it would be hanging forever. The other two command seems to work fine somehow. Steps To Reproduce Kinda hard, cause I can't share the repo. 1. Running `docker compose up` with on our repo 2. Hangs forever - will get killed after an hour on CI, thanks to gitlab (usually builds need around 8 min) Compose Version [code block] Docker Environment [code block] Anything else? Opting out of `bake` seems to solve the problem for us now on CI.
Secrets fail to set the `uid`, `gid` and `mode` specified in `docker-compose.yml`
Description Docker secrets specified using the long syntax for the `docker-compose.yml` file fail to set the specified `uid`, `gid` and `mode`. Also, from the docs, the default value of the `uid` and `gid` fields should be the user that runs the container however the value remains whatever was set on the host machine. Steps to reproduce the issue: 1. Create a `Dockerfile` [code block] 2. Create a `docker-compose.yml` [code block] 3. Create a text file for secrets (`somefile.txt`) [code block] 4. Run the service `docker compose run secrets-tester` Describe the results you received: Received Output: [code block] Describe the results you expected: Expected Output: [code block] Additional information you deem important (e.g. issue happens only occasionally): Same behavior is observed in these cases: 1. Without creating the `tester` user 2. With same `source` and `target` names for the file in `docker-compose.yml` 3. Using the `uid` and `gid` for `root` 4. Using random values for `uid` and `gid` 5. Different values for `mode` Output of `docker compose version`: [code block] Output of `docker info`: [code block] Additional environment details:
Binary on darwin fails with "illegal instruction" on some machines
The current `fig` release doesn’t work for me: [code block] I’m running OS X 10.9.3 on a 1.6 GHz Intel Core 2 Duo (Late 2010 MacBook Air).
docker-compose build and docker build lead to different IDs
When building containers for my project I noticed that, even if I build from the same Dockerfile, `fig` and `docker` build different image IDs in the end. I also tried to use the same tag, but the images still were different. Built with fig: [code block] Built with docker: [code block] `ec26eedffc59` and `8fecc44750ee` is the same file, but added with different IDs. Is there anything I've overlooked or is this a bug? Using fig 1.0.1 docker 1.3.2.
Proposal: docker-compose events
There have been a few requests for supporting some form of "hooks" system within compose (#74, #1341). A feature which runs commands on the host would add a lot of complexity to compose and the compose configuration. Another option is to support these features by providing a way for external tools to run the command triggered by an event. docker events provides an event stream of all docker events, but would still require filtering. `docker-compose events` could provide a similar interface by filtering the events returned by `/events` and return a stream of only the events related to the active compose project. The event stream could also include a new field `"service": <service_name>` in addition to the fields already provided by `/events`
dns configuration option does not work on docker-compose==1.6.0
Step 1: [code block] Step 2: [code block] Step 3: [code block] As you can see, `dns` option is ignored by `docker-compose` and some garbage is set instead. This prevents my containers from starting up because they require to use mentioned DNS server. BTW, what kind of shit is 127.0.0.11, and how it get to resolve.conf? With version 1 of yaml file everything is working as expected (nameserver is set correctly).
Epic: "compose run" should support every "docker run" option
`fig run` should support every option of `docker run`, just referring to a service instead of an image. [code block] Todo (in rough priority order) - [x] `-u` https://github.com/docker/compose/pull/971 - [x] `--entrypoint` https://github.com/docker/compose/pull/511 - [x] `-w` https://github.com/docker/compose/pull/332 - [x] `-p` https://github.com/docker/compose/issues/1709 - [x] `-v` - [x] `--cpuset` - [x] `--memory` - [x] `--env-file` - [x] `--net` - [x] `--memory-swappiness` #2383 - [ ] `--volumes-from` #1769
Compose error "HTTP request took too long to complete"
Lately I've been noticing the following error message quite frequently with `docker-compose up`: [code block] Increasing the `COMPOSE_HTTP_TIMEOUT` only seems to delay the error. Is this a known issue and/or is there a workaround for this? I'm using ubuntu 16.04, please find below the output of `docker-compose version` and `docker version`. I'd also like to note that I see this issue with docker for mac beta, docker-machine, etc. [code block] [code block]
failed to get console mode for stdout: The handle is invalid.
Description of the issue The `docker-compose build` command prints this `failed` error every time. Context information (for bug reports) Output of `docker-compose version` [code block] Output of `docker version` [code block] Output of `docker-compose config` (Make sure to add the relevant `-f` and other flags) [code block] and the Dockerfile can be anything, this works [code block] Steps to reproduce the issue 1. Create any Dockerfile on Windows 2. Create any Docker Compose manifest with a build section pointing to the same Dockerfile 3. Run `docker-compose build` Observed result The Docker Compose build command always prints the `failed` line. Nothing else _seems_ to be wrong, but I'm not sure. [code block] Expected result The plain Docker build command works as expected. [code block] Stacktrace / full error message [code block] Additional information OS version / distribution, `docker-compose` install method, etc.
"http: Hijack is incompatible with use of CloseNotifier in same ServeHTTP call" errors
Using 1.8-rc1 and docker 1.12-rc3 with the following compose file: [code block] and Dockerfile: [code block] If I do: [code block] Looks like a missed case in https://github.com/docker/compose/pull/1374 cc @dnephin
Command-line completion?
I just wonder if there's a command completion like there is for the docker-compose command.
"driver failed programming external connectivity on endpoint" (1.7.0-rc1)
I'm pretty sure this was working on docker-compose 1.7.0-rc1 before I installed the latest Docker for Mac beta, which upgraded to docker 1.11.0-rc3. I'm trying to get the socat service to run on port 172.17.0.1:8123, so that it's available to docker builds. My real yml uses an environment variable for the IP address, but it happens even when hardcoded. [code block] [code block] verbose.txt
Fig can't connect to DOCKER_HOST=tcp://
On OS X with `boot2docker` 0.5.4: [code block] `docker build .` worked fine for me, but `fig` seems unable to handle the `tcp://` URL.
Add `copy` to the yaml configuration
I want to deploy different services using the same image but with a different configuration file. Currently to achieve that I can - build as many images that inherit from a common image plus a different COPY in each - mount a single file volume The first solution isn't feasible and the second it's overkill. I just want to copy a file, not keep it in sync Proposed configuration: [code block]
Proposal: make project-name persistent.
By default, Compose bases the project name on basename of the directory compose commands are run from. The project name can be overridden either by passing a `-p / --project-name` option for each command or setting the `COMPOSE_PROJECT_NAME` environment variable. Using the `--project-name` option for _each_ command is error-prone and for- getting to pass the option when doing (for example) `docker-compose up`, will result in _another_ instance of the project being created under a different name or even containers of a different project being replaced. Using the `COMPOSE_PROJECT_NAME` environment variable is not useful when dealing with multiple projects and can cause similar problems. Proposal: make project-name persistent To solve these problems, compose will save the name of a project to a file in the build-context when the project is first started / built. If a project-file is found, compose automatically uses the project-name from that file and throw an exception if the user is trying to override the project-name using the `--project-name` option. File location To allow further expansion of options, compose creates a hidden `.docker-compose` directory in the "root" directory of the build-context. Inside that directory, a `project-name` file is created, containing just the name of the project; [code block] Request for comment There are a couple of things left to be discussed; - Should the configuration-file be created _automatically_ or should this be an exp
[BUG] service can't be used with `extends` as it declare `depends_on`
Description When trying to bring up a compose project that makes use of `extends` feature, I am getting the following error: [code block] Steps To Reproduce 1. Have a docker-compose.yml project with extends, like this: [code block] and the nginx/compose.yml: [code block] 2. `docker compose up` 3. See error: service "nginx" can't be used with `extends` as it declare `depends_on` Compose Version [code block] Docker Environment [code block] Anything else? _No response_