Pause/unpause was being partially tested under the start/stop test.
This removes it from that test and adds dedicated pause + unpause
tests.
Note that the tests assert on current behavior, though it's been
noted where that is undesirable due to divergence from the Docker
CLI. Will change the behavior + update tests in a subsequent PR.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
As of Go 1.16, the same functionality is now provided by package io or
package os, and those implementations should be preferred in new code.
So replacing all usage of ioutil pkg with io & os.
Signed-off-by: Abhinav Nair <11939846+abhinavnair@users.noreply.github.com>
When using the "classic" (non-BuildKit) builder, ensure that
services are iterated in dependency order for a build so that
it's possible to guarantee the presence of a base image that's
been added as a dependency with `depends_on`. This is a very
common pattern when using base images with Compose.
A fix for BuildKit is blocked currently until we can rely on a
newer version of the engine (see docker/compose#9324)[^1].
[^1]: https://github.com/docker/compose/issues/9232#issuecomment-1060389808
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Within the Docker API/engine, networks have unique IDs, and the
name is a friendly label/alias, which notably does NOT have any
guarantees around uniqueness (see moby/moby#18864 [^1]).
During day-to-day interactive/CLI Compose usage, this is rarely
an issue, as Compose itself isn't creating networks concurrently
across goroutines. However, if multiple Compose instances are
executed simultaneously (e.g. as part of a test suite that runs
in parallel), this can easily occur.
When it does happen, it's very confusing for users and resolving
it via the `docker` CLI is not straightforward either [^2].
There's two primary changes here:
* Pass `CheckDuplicates: true` to the Docker API when creating
networks to reduce the likelihood of Compose creating duplicates
in the first place
* On `down`, list networks using a name filter and then remove
them all by ID, as the Docker API will return an error if the
name alias is used and maps to more than one network
Hopefully, this provides a better UX, since the issue should be
less likely to occur, and if it does, it can now be resolved via
standard Compose workflow commands.
[^1]: https://github.com/moby/moby/issues/18864
[^2]: https://stackoverflow.com/questions/63776518/error-2-matches-found-based-on-name-network-nameofservice-default-is-ambiguo
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Also add e2e tests to ensure `compose up --wait` does not get stuck forever waiting for one-shot containers
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
This is mostly marking a bunch of the run methods as helpers so
that the internal assertions they do will show the line number of
the calling test instead.
There's also some small tweaks around the plugin initialization to
help with the output in the event that it fails to make it easier
to debug what went wrong.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
This was using `docker exec` on Compose containers instead of
`docker compose exec` (and `docker-compose exec` for standalone).
Thanks to @glours for catching!
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
The E2E tests can be run in plugin (`docker compose`) or standalone
(`docker-compose`) mode. Existing logic was in place to ensure that
the helper method is always used, which will invoke the right one
based on how tests are being executed.
However, this logic was too easy to (unintentionally) bypass given
the myriad of ways that commands can be run. The check has been
made stricter and pushed to a lower-level to more aggressively
catch instances.
As a result, a bunch of calls to `RunDockerCmd` are now updated
to be `RunDockerComposeCmd`, which will ensure that the invocation
is correct based on test mode.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Use the command `stdout` instead of combined `stdout` + `stderr`
for assertions to avoid failures from any CLI logging such as
warnings, which will be on `stderr`.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
The most important change here is to ensure that the correct Compose
standalone binary is used by `ddev`. Since it invokes Compose itself,
we need to ensure that `PATH` is set appropriately such that it finds
the binary we want to test rather than something from the system.
As part of this, the rest of the environment has been isolated, which
should make the test more reliable, and avoids polluting `~/.ddev`
with test artifacts by using a tmpdir as `HOME` for the test instead
of the user's real home folder.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
When running Docker / Compose commands, do NOT inherit the system
environment to ensure that the tests are reproducible regardless
of host settings.
Additionally, per-command environment overrides are provided to
the command instead of using `os.SetEnv`, as this is not safe when
running tests in parallel (`testing.T::SetEnv` will actually error
if used in this way!)
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
The big mechanical change here is to NOT store `t` as a field on
the `CLI` object (which has been renamed as well to fix the odd
capitalization). The way the tests are structured meant that the
"subtests" were using the _parent_ `*testing.T` instance, which
causes various oddities including confusing messages on failure
about a child test causing a panic in the parent.
Additionally, a few tests have been blocked from running in
parallel because they are sharing `compose.yaml` fixtures and
can fail as a result (e.g. due to a port conflict on the host).
I'll fix these in follow-up PRs but want to focus on correctness
for the tests before optimizing them.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
In v1, links were sent alongside the rest of the container create request, as part of `HostConfig`. In v2, links are usually set on the connect container to network request that happens after the create. However, this only happens if the service has one or more networks defined for it. If the services are configured to use the default bridge network, this request is not made and so links are never configured.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
`NetworkInspect` will match a network ID by prefix. While rare,
it's possible that users might use a network name that is also
a valid network ID prefix for a pre-existing Docker network.
(In the reported case, the network was named `db`, for example.)
Fixes#9496.
Signed-off-by: Milas Bowman <milas@tilt.dev>
A command down without any resource to delete was
trying to remove a default network that doesn't exist
Signed-off-by: Ulysses Souza <ulyssessouza@gmail.com>
This commit adds progress output while waiting for `depends_on`
conditions to resolve. The initial output looks like so:
⠿ Container chbench-zookeeper-1 Waiting 0s
⠿ Container chbench-kafka-1 Waiting 0s
⠿ Container chbench-one-off Waiting 0s
Once all conditions have been resolved, the ouput looks like this:
⠿ Container chbench-zookeeper-1 Healthy 1.2s
⠿ Container chbench-kafka-1 Healthy 3.2s
⠿ Container chbench-schema-registry-1 Exited 4s
As shown above, `service_healthy` conditions result in a terminal status
of "Healthy" while `service_exited_successfully` conditions result in a
terminal status of "Exited".
Signed-off-by: Nikhil Benesch <nikhil.benesch@gmail.com>
The previous code would wait for dependencies to become healthy forever,
even if they'd become unhealthy in the meantime. I can't find an issue
report for this bug, but it was described in a comment on the PR that
introduced the `--wait` flag [0].
[0]: https://github.com/docker/compose/pull/8777#issuecomment-965643839
Signed-off-by: Nikhil Benesch <nikhil.benesch@gmail.com>
Added unsupported volume bind option SELinux label `:z` and `:Z` in v2.
It is a regression compared to v1 written in Python.
The v2 uses the compose-spec/compose-go to parse Compose YAML
specification files but there was missing support for volume bind option
SELinux label `:z` and `:Z` in parser. It is fixed in:
- https://github.com/compose-spec/compose-go/pull/213
It fixes#9072
References:
- https://docs.docker.com/storage/bind-mounts/#configure-the-selinux-label
Signed-off-by: Tymoteusz Blazejczyk <tymoteusz.blazejczyk@tymonx.com>
The `group_add` key is parsed correctly from a compose file, but it is not
passed into the `ContainerCreate` API call, thus the configuration does
not take effect. This commit fixes the issue by propagating the
configuration from Docker compose's ServiceConfig to Docker container's
HostConfig.
Signed-off-by: Lance Chen <hello@lancechen.tw>
Intermediate containers remain even when build succeeded
when building with classic way (i.e. not with buildkit).
Remove them when build succeeded like default behavior of docker build.
Signed-off-by: notok <noto.kazufumi@gmail.com>
Guillaume Lours
Laura Brehm
Milas Bowman
Laura Brehm
Abhinav Nair
Nick Sieger
Nicolas De Loof
Bastian Venthur
Ulysses Souza
Milas Bowman
Randy Fay
Maxime CLEMENT
Eric Fan
PIG208
Vedant Koditkar
Mehrad Dadar
Mehrad Dadar
Ulysses Souza
Yuri Kanivetsky
Nikhil Benesch
Tymoteusz Blazejczyk
Lance Chen
notok