An image is built anyway, so this is unnecessary. This makes it
possible to run the tests on a remote Docker daemon.
Signed-off-by: Ben Firshman <ben@firshman.co.uk>
I think the original intention of the original test was the check that
different signals work, I think. This does this -- it sends a signal
that doesn't cause the container to stop.
Closes#759. Replaces #1467.
Signed-off-by: Ben Firshman <ben@firshman.co.uk>
This adds a command 'version' to show software versions information
like Docker does. In addition it includes:
- version of the docker-py-package
- Python-implementation and -version
Signed-off-by: Frank Sachsenheim <funkyfuture@riseup.net>
This fixes a bug where migration would fail with an error if a
downstream container was migrated before its upstream dependencies, due
to `check_for_legacy_containers()` being implicitly called when we fetch
`links`, `volumes_from` or `net` dependencies.
Signed-off-by: Aanand Prasad <aanand.prasad@gmail.com>
When an upstream dependency (e.g. a db) has a container but a downstream
service (e.g. a web app) doesn't, a web container is not created on
`docker-compose up`.
Signed-off-by: Aanand Prasad <aanand.prasad@gmail.com>
"Define and run multi-container applications with Docker"
Not just development environments, and "complex" is not clear and
not really true.
Signed-off-by: Ben Firshman <ben@firshman.co.uk>
- One-off containers were included in the warning log messages, which can
make for unreadable output when there are lots (as there often are).
- Compose was attempting to recreate one-off containers as normal
containers when migrating.
Fixed by implementing the exact naming logic from before we used labels.
Signed-off-by: Aanand Prasad <aanand.prasad@gmail.com>
- Rename `migration` module to `legacy` to make its legacy-ness explicit
- Move `check_for_legacy_containers` into `legacy` module
- Fix migration test so it can be run in isolation
Signed-off-by: Aanand Prasad <aanand.prasad@gmail.com>
If we're just streaming logs from `docker-compose up`, we don't need
to set AttachStdin/out/err, and doing so results in containers with
different configuration depending on whether `up` or `run` were invoked
with `-d` or not.
Signed-off-by: Aanand Prasad <aanand.prasad@gmail.com>
We shouldn't start the container before handing it off to dockerpty -
dockerpty will start it after attaching, which is the correct order.
Otherwise the container might exit before we attach to it, which can
lead to weird bugs.
Signed-off-by: Aanand Prasad <aanand.prasad@gmail.com>