Nicolas De loof

Once you configure logging driver to `none` then docker engine won't store container logs ... obvioulsy And then this is expected you can't later retrieve logs (arguably, the engine error...

@lvaneijden ok makes sense. So 1. we should not fail when a service is configured with logging driver:none (show a warning) 2. introduce some `--no-attach=xx` (or a better noun? `--silent=service`?)...

buildkit has been made the default builder (see https://github.com/docker/docs/pull/12505)

The IMAGE ID reported by `docker images ls` is actually truncated to 12 characters, which maybe let you think those are the same IDs but actually would need to run...

Docs has been revisited and https://docs.docker.com/compose/completion/#available-completions doesn't point to any relevant page for this issue. As a CLI plugin, docker compose v2 relies on `docker` top-level command support for dynamic...

I'm in favor for container hooks, comparable to [Kubernetes lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/), as this could cover many use cases, like the typical "_intialize database with dataset_". Anyway that should be discussed...

I created a proposal on this topic (at least, partially) feel free to comment/suggest changes https://github.com/compose-spec/compose-spec/pull/289

I'm aware my proposal only **partially** address this issue. it is heavily inspired by kubernetes lifecycle hooks, which is a proven solution I'm 👎 on running local commands from compose,...

again, I'm not saying https://github.com/compose-spec/compose-spec/pull/289 intent is to fully support this feature request. This just sounds to me a reasonable addition on this topic. About running host commands, I won't...

@benitogf such "setup" scenario can also be supported using an entrypoint script. Up to you to make this one idempotent, so running it after first command doesn't impact the deployment...