* logs: filter to services from current Compose file
When using the file model, only attach to services
referenced in the active Compose file.
For example, let's say you have `compose-base.yaml`
and `compose.yaml`, where the former only has a
subset of the services but are both run as part of
the same named project.
Project based command:
```
docker compose -p myproj logs
```
This should return logs for active services based
on the project name, regardless of Compose file
state on disk.
File based command:
```
docker compose --file compose-base.yaml logs
```
This should return logs for ONLY services that are
defined in `compose-base.yaml`. Any other services
are considered 'orphaned' within the context of the
command and should be ignored.
See also #9705.
Fixes#9801.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Re-evaluate DockerCli and APIClient after reading the environment file.
I can contain DOCKER_HOST and/or DOCKER_CONTEXT so the DockerCli passed by docker/cli has to be re-evaluated.
Also checks for DOCKER_CERT_PATH and DOCKER_TLS_VERIFY.
Signed-off-by: Ulysses Souza <ulyssessouza@gmail.com>
When running `compose down`, the `--rmi` flag can be passed,
which currently supports two values:
* `local`: remove any _implicitly-named_ images that Compose
built
* `all` : remove any named images (locally-built or fetched
from a remote repo)
Removing images in the `local` case can be problematic, as it's
historically been done via a fair amount of inference over the
Compose model. Additionally, when using the "project-model"
(by passing `--project-name` instead of using a Compose file),
we're even more limited: if no containers for the project are
running, there's nothing to derive state from to perform the
inference on.
As a first pass, we started labeling _containers_ with the name
of the locally-built image associated with it (if any) in #9715.
Unfortunately, this still suffers from the aforementioned problems
around using actual state (i.e. the containers might no longer
exist) and meant that when operating in file mode (the default),
things did not behave as expected: the label is not available
in the project since it only exists at runtime.
Now, with these changes, Compose will label any images it builds
with project metadata. Upon cleanup during `down`, the engine
image API is queried for related images and matched up with the
services for the project. As a fallback for images built with
prior versions of Compose, the previous approach is still taken.
See also:
* https://github.com/docker/compose/issues/9655
* https://github.com/docker/compose/pull/9715
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Go released 1.18.6 + 1.19.1 today which fix a couple
CVEs. (`golang.org/x/net` also has a related fix.)
This jumps from 1.18.5 -> 1.19.1 since it was on the
to-do list regardless :)
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
support DOCKER_DEFAULT_PLATFORM when 'compose up --build'
add tests to check behaviour when DOCKER_DEFAULT_PLATFORM is defined
Signed-off-by: Guillaume Lours <705411+glours@users.noreply.github.com>
There's a complex dependency situation with `docker/docker`,
`docker/cli`, and `docker/buildkit`. Upgrading them usually
needs to happen in unison to ensure compatible versions
between them, particularly because `docker/buildx` is not
1.0, so has no guarantees re: compatibility, and `docker/docker`
& `docker/cli` use CalVer rather than SemVer, so also have
different compatibility guarantees than necessarily expected
by Go tooling.
Patch versions are still considered for these to ensure we
don't miss important bugfixes.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Ensure that everything works nicely for `docker-ce-packaging`
as well as local development.
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
Revert "Merge pull request #9745 from ulyssessouza/apply-newly-loaded-envvars"
This reverts commit 6fe34c45cad8790da99f195f3269eca0e8f0fc0b, reversing
changes made to 10cfd551e3f1e6428dbcf16f480a1fdbaaf92986.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
