Nicolas De loof

Results 981 comments of Nicolas De loof

I'm not aware of such an issue with v2. Gave a quick try using this minimal compose.yaml file: ```yaml services: c1: image: nginx depends_on: - c2 c2: image: nginx ```...

docker compose v1 indeed use the logging API, and doing so won't collect any log when driver is set to `none`. docker compose v2 attach to container (just like docker...

`docker compose up --detach SERVICE` unfortunately doesn't make it clear is SERVICE applies to the detach option or is set to select services to be started by `up`. I guess...

You're right about `--attach` flag, indeed offers this as a recently introduced flag (I forgot about this one, whenever I'm the one who [introduced it](https://github.com/docker/compose/commit/e8666b02f356a2e2549cabc311e5c28e6316a7cb), seems my brain sometime needs...

panic is triggered from https://github.com/docker/compose-cli/blob/v2.0.0-beta.3/cli/cmd/compose/exec.go#L100 which is guarded by `execOpts.Tty = !opts.tty`, so running with `-T` you _should_ not run this code. @lorenrh isn't this the same issue you already...

I'm also not convinced use of os.stderr to display information on the current operation is not the best decision we made. unfortunately there's nothing like os.stdinfo we could rely on...

I'm not sure why/how this behavior exists with docker-compose v1, but that sounds weird to me an explicit bind mount does not override the image content. I can understand the...

root cause is: as service image is pulled during `up`, `com.docker.compose.image` label is not set

Engine do support passing `--env-file /dev/null` so compose should do the same

@a-abella yes, I fully agree. As I said "docker run does, so compose should do the same" As the reported use-case was to be able to pass extra environment file,...