I'm not sure if it should be there at all, but at least it should hardly be where it currently is located.
Signed-off-by: Per Persson <per.persson@exertisztorm.com>
This change adds cgroup-parent support to compose project. It allows
each service to specify a 'cgroup_parent' option.
Signed-off-by: Mohit Soni <mosoni@paypal.com>
Also incorporated the structural changes by @moxiegirl in PR #1994 as well as subsequent issues reported by @aanand.
Signed-off-by: Charles Chan <charleswhchan@users.noreply.github.com>
splitdrive doesn't handle relative paths, so if volume_path contains
a relative path, we handle that differently and manually set drive to ''.
Signed-off-by: Mazz Mosley <mazz@houseofmnowster.com>
Removed 'Compose command line completion' and 'Compose environment variables' from the list. command line completion is linked to from install docs, and environment variables are deprecated.
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Remove Set-PSDebug -trace to prevent the 9000+ lines of debug output
from spamming the logs on appveyor.
Signed-off-by: Daniel Nephin <dnephin@docker.com>
The Dockerfile should use the same Gemfile.lock as the app, to make sure the container gets the expected versions of gems installed. Aside from wanting that in principle, without it you can get mysterious gem dependency errors. Here's the scenario:
1. Suppose `Gemfile` includes `gem "some-active-gem", "~> 1.0"
2. When developing the app, you run `bundle install`, which installs the latest version--let's say, 1.0.1-and records it in `Gemfile.lock`
3. Suppose the developers of `some-active-gem` then release v1.0.2
4. Now build the container: docker runs `bundle install`, which installs v1.0.2 and records it in `Gemfile.lock` and then "ADD"s the app worktree, which replaces the `Gemfile.lock` with the one from the worktree that lists v1.0.1.
5. Immediately run your app and it fails with the error `Could not find some-active-gem-1.0.1 in any of the sources` which is a bit befuddling since you just saw it run bundle install so you expect all gem dependencies to be resolved properly.
Signed-off-by: ronen barzel <ronen@barzel.org>
Including examples of more boolean types, eg yes/N as it's not
always immediately clear that they are treated as booleans.
Signed-off-by: Mazz Mosley <mazz@houseofmnowster.com>
Rather than inefficiently looping through all the containers that a
service has and overriding each volumes_from value, pick the first
one and return that.
Signed-off-by: Mazz Mosley <mazz@houseofmnowster.com>
