Fix the issue when build arg is set to None instead of empty string. Usecase:
cat docker-compose.yml
.... args:
- http_proxy
- https_proxy
- no_proxy
If http_proxy, https_proxy, no_proxy environment variables are not defined then http_proxy,
https_proxy, no_proxy build args will be set to string None which breaks all downloads
With this change undefined build args will be set to empty string instead of string None
Signed-off-by: Andrey Devyatkin <andrey.a.devyatkin@gmail.com>
Fix the issue when build arg is set to None instead of empty string. Usecase:
cat docker-compose.yml
.... args:
- http_proxy
- https_proxy
- no_proxy
If http_proxy, https_proxy, no_proxy environment variables are not defined then http_proxy,
https_proxy, no_proxy build args will be set to string None which breaks all downloads
With this change undefined build args will be set to empty string instead of string None
Signed-off-by: Andrey Devyatkin <andrey.a.devyatkin@gmail.com>
Previously these empty objects would hit a bug in splitting objects causing it crash.
With this fix the empty objects are returned properly.
Signed-off-by: Daniel Nephin <dnephin@docker.com>
We were outputting an extra line, which in *some* cases, on *some*
terminals, was causing the output of parallel actions to get messed up.
In particular, it would happen when the terminal had just been cleared
or hadn't yet filled up with a screen's worth of text.
Signed-off-by: Aanand Prasad <aanand.prasad@gmail.com>
If we get back an error that wasn't an APIError, it was causing the
thread to hang. This catch all, while I appreciate feels risky to
have a catch all, is better than not catching and silently failing,
with a never ending thread.
If something worse than an APIError has gone wrong, we want to stop
the incredible journey of what we're doing.
Signed-off-by: Mazz Mosley <mazz@houseofmnowster.com>
It was harder to see when there are errors if they came straight after
the other output. Putting a newline in there gives it a bit of visual
room.
Signed-off-by: Mazz Mosley <mazz@houseofmnowster.com>
Refactored parallel execute and execute create into a single function
parallel_execute that can now handle both cases. This helps untangle it
from being so tightly coupled to the container.
Updated all the relevant operations to use the refactored function.
Signed-off-by: Mazz Mosley <mazz@houseofmnowster.com>
The concurrent.futures backport doesn't play well with
KeyboardInterrupt, so I'm using Thread and Queue instead.
Since thread pooling would likely be a pain to implement, I've just
removed `COMPOSE_MAX_WORKERS` for now. We'll implement it later if we
decide we need it.
Signed-off-by: Aanand Prasad <aanand.prasad@gmail.com>
Sometimes, some messages were being executed at the same time, meaning
that the status wasn't being overwritten, it was displaying on a
separate line for both doing and done messages.
Rather than trying to have both sets of statuses being written out
concurrently, we write out all of the doing messages first. Then
the done messages are written out/updated, as they are completed.
Signed-off-by: Mazz Mosley <mazz@houseofmnowster.com>
This approach takes the style of replacing the output message, in
place, when the command has finished executing. Bringing it a bit
more inline with what `docker pull` does.
Signed-off-by: Mazz Mosley <mazz@houseofmnowster.com>
Commands able to use this parallelisation are `stop`, `kill` and `rm`.
We're using a backported function from python 3, to allow us to make
the most of a pool of threads without having to write the low level
code for managing this ourselves.
A default value for number of threads is a low enough number so it
shouldn't cause performance problems but if someone knows the
capability of their system and wants to increase it, they can via
an environment variable DEFAULT_MAX_WORKERS
Signed-off-by: Mazz Mosley <mazz@houseofmnowster.com>
Andrey Devyatkin
Joffrey F
Daniel Nephin
Daniel Nephin
Aanand Prasad
Mazz Mosley
Ben Firshman