this test checks if exposing a large number of ports in Dockerfile properly
saves the port in configs. We dont actually expose a VERY large number of ports
here because the result is the same and it increases the test time by a few
seconds
Docker-DCO-1.1-Signed-off-by: Daniel, Dao Quang Minh <dqminh89@gmail.com> (github: dqminh)
Saving ports as `map[nat.Port]struct{}` directly has ordering issue which is
more replicatable where we expose a huge number of ports at the same time. As a
result, the cache will be burst whenever the map order is different from the
previous build.
This sorts the ports first and save them as a whitespace-separated list instead
of the map representation, so the order will always be consistent if the port
list isnt changed.
NOTICE: this will burst the old expose caches
Docker-DCO-1.1-Signed-off-by: Daniel, Dao Quang Minh <dqminh89@gmail.com> (github: dqminh)
changing order of EXPOSE ports should not invalidate the cache as the content
doesnt change
Docker-DCO-1.1-Signed-off-by: Daniel, Dao Quang Minh <dqminh89@gmail.com> (github: dqminh)
Whenever a command arguments is formed by a large linked list, repeatedly
appending to arguments and displayed messages took a long time because go will
have to allocate/copy a lot of times.
This speeds up the allocation by preallocate arrays of correct size for args
and msg
Docker-DCO-1.1-Signed-off-by: Daniel, Dao Quang Minh <dqminh89@gmail.com> (github: dqminh)
I noticed a few things that were bugging me in the output
of the integration-cli tests.
- one of the tests used println to stdout so we had garage sent to the screen
- some of the test, in their final log message, didn't include the name of
the group/file e.g. daemon - run,iptables was just run,iptables
And yes, I noticed this because I'm anal :-) but also because we should keep
the output of the tests as clean as possible so its easy to spot it when
things go bad.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Linking to the docs readme to help would-be contributors discover the style guide and docs contribution guidelines.
Docker-DCO-1.1-Signed-off-by: Fred Lifton <fred.lifton@docker.com> (github: fredlf)
Running parseVolumesFromSpec on all VolumesFrom specs before initialize
any mounts endures that we don't leave container.Volumes in an
inconsistent (partially initialized) if one of out mount groups is not
available (e.g. the container we're trying to mount from does not
exist).
Keeping container.Volumes in a consistent state ensures that next time
we Start() the container, it'll run prepareVolumes() again.
The attached test demonstrates that when a container fails to start due
to a missing container specified in VolumesFrom, it "remembers" a Volume
that worked.
Fixes: #8726
Signed-off-by: Thomas Orozco <thomas@orozco.fr>
Signed-off-by: Prasanna Gautam <prasannagautam@gmail.com>
I found that certain docker installations do not handle binding to the source directory quite right. Just writing it based on help from backjlack and tibor in IRC.
This patch fixes the compilation errors in Docker due to changes in the
libcontainer/user API. There is no functionality change due to this
patch.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> (github: cyphar)
This patch updates the vendor'd libcontainer version, so that Docker can
take advantage of the updates to the `user` API.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> (github: cyphar)
Removing Sonat from docs maintainers because he no longer has time to complete all the responsibilities. Many thanks to Sonat for his help.
Docker-DCO-1.1-Signed-off-by: Fred Lifton <fred.lifton@docker.com> (github: fredlf)
The current implementation of the Docker Hub returns a list of objects
containing the tag name and the layer id.
Docker-DCO-1.1-Signed-off-by: Vincent Giersch <vincent.giersch@ovh.net>