CIs are assumed to do a git fetch and git merge before running tests.
Therefore, no need for a git fetch inside our validate scripts in CI.
If VALIDATE_ORIGIN_BRANCH is set, then git fetch is skipped and
VALIDATE_ORIGIN_BRANCH is used in validate scripts.
Otherwise, behavior is unchanged.
Signed-off-by: Tibor Vass <tibor@docker.com>
(cherry picked from commit feb70fd5c9e2fb3f300e953dd83053f0830f3895)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 7b9ec00eec7ffe745ebd2f807daa50d84b3e10e7
Component: engine
When running CI in other repositories (e.g. Docker's downstream
docker/engine repository), or other branches, the validation
scripts were calculating the list of changes based on the wrong
information.
This lead to weird failures in CI in a branch where these values
were not updated ':-) (CI on a pull request failed because it detected
that new tests were added to the deprecated `integration-cli` test-suite,
but the pull request did not actually make changes in that area).
This patch allows overriding the target repository (and branch)
to compare to (without having to edit the scripts).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 2a08f33166247da9d4c09d4c6c72cbb8119bf8df)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 748f37022df465c39a76461c4970f4c678f629e3
Component: engine
containerd has two objects with regard to containers.
There is a "container" object which is metadata and a "task" which is
manging the actual runtime state.
When docker starts a container, it creartes both the container metadata
and the task at the same time. So when a container exits, docker deletes
both of these objects as well.
This ensures that if, on start, when we go to create the container metadata object
in containerd, if there is an error due to a name conflict that we go
ahead and clean that up and try again.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 5ba30cd1dc6000ee53b34f628cbff91d7f6d7231)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 1d0353548a21b0b60595ad44859a7072f90ea6c6
Component: engine
for windows all networks are re-populated in the store during network controller initialization. In current version it also regenerate network Ids which may be referenced by other components and it may cause broken references to a networks. This commit avoids regeneration of network ids.
Signed-off-by: Andrey Kolomentsev <andrey.kolomentsev@docker.com>
(cherry picked from commit e017717d96540dd263d95f90fdb2457928909924)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 317e0acc4e602f978e4d9c0130a113d179026c8e
Component: engine
A git bundle allows us keep the same SHA, giving us the ability to
validate our patch against a known entity and allowing us to push
directly from our private forks to public forks without having to
re-apply any patches.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 03dfb0ba53cc5f64b746a25aa5ed8a48763ea223
Component: engine
- Fix a bug that a container can't be stopped or inspected when its corresponding image is deleted
- Fix a bug that the cri plugin handles containerd events outside of k8s.io namespace
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 27cc170d2891f25ab066620e8fe94d62f81b9aa3)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: f80c6d7ae15443f15c014ddbd17e30cfac47b906
Component: engine
RHEL/CentOS 3.10 kernels report that kernel-memory accounting is supported,
but it actually does not work.
Runc (when compiled for those kernels) will be compiled without kernel-memory
support, so even though the daemon may be reporting that it's supported,
it actually is not.
This cause tests to fail when testing against a daemon that's using a runc
version without kmem support.
For now, skip these tests based on the kernel version reported by the daemon.
This should fix failures such as:
```
FAIL: /go/src/github.com/docker/docker/integration-cli/docker_cli_run_unix_test.go:499: DockerSuite.TestRunWithKernelMemory
assertion failed:
Command: /usr/bin/docker run --kernel-memory 50M --name test1 busybox cat /sys/fs/cgroup/memory/memory.kmem.limit_in_bytes
ExitCode: 0
Error: <nil>
Stdout: 9223372036854771712
Stderr: WARNING: You specified a kernel memory limit on a kernel older than 4.0. Kernel memory limits are experimental on older kernels, it won't work as expected and can cause your system to be unstable.
Failures:
Expected stdout to contain "52428800"
FAIL: /go/src/github.com/docker/docker/integration-cli/docker_cli_update_unix_test.go:125: DockerSuite.TestUpdateKernelMemory
/go/src/github.com/docker/docker/integration-cli/docker_cli_update_unix_test.go:136:
...open /go/src/github.com/docker/docker/integration-cli/docker_cli_update_unix_test.go: no such file or directory
... obtained string = "9223372036854771712"
... expected string = "104857600"
----------------------------------------------------------------------
FAIL: /go/src/github.com/docker/docker/integration-cli/docker_cli_update_unix_test.go:139: DockerSuite.TestUpdateKernelMemoryUninitialized
/go/src/github.com/docker/docker/integration-cli/docker_cli_update_unix_test.go:149:
...open /go/src/github.com/docker/docker/integration-cli/docker_cli_update_unix_test.go: no such file or directory
... value = nil
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 1e1156cf67233cf8eaee2da9c17465ff0d9c2aa0)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: e042692db1316a60be35bfdca10d7e08d20f50ad
Component: engine
Revert "[18.09 backport] API: fix status code on conflicting service names"
Upstream-commit: ce8b8f1cf33bb33811077be3b0b972dd2dbc4c79
Component: engine
This includes a patch on top of containerd 1.2.1 to handle fifo
timeouts.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
(cherry picked from commit e5d9d721626958a37dccfa0b234d9fc96d8c2bfb)
Signed-off-by: Andrew Hsu <andrewhsu@docker.com>
Upstream-commit: d161dfe1a36929a03ee3dfa916d296abfd4ccef1
Component: engine
go1.10.6 (released 2018/12/14)
- crypto/x509: CPU denial of service in chain validation golang/go#29233
- cmd/go: directory traversal in "go get" via curly braces in import paths golang/go#29231
- cmd/go: remote command execution during "go get -u" golang/go#29230
See the Go 1.10.6 milestone on the issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.10.6
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 8afe9f422dc0183ce48e1db09189ccbde634080a
Component: engine
[18.09 backport] fixes display text in Multiple IDs found with provided prefix
Upstream-commit: a8572d3e8e1e3f738d6e9bc3bf0f137d64bab616
Component: engine
This avoids the corner case where `via` is not nil, but has a length of 0,
so the updated code does not panic in that situation.
Signed-off-by: Iskander Sharipov <quasilyte@gmail.com>
(cherry picked from commit a5c185b99404ea3fbab47ff9d7ba143392566bc1)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 3482a3b14a6414977bd9860c513abf06dedd6bf7
Component: engine
This updates the swarmkit vendoring to the latest version in the bump_v18.09
branch
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: ad7105260f3c2ff32a375ff78dce9a96e01d87cb
Component: engine
go1.10.5 (released 2018/11/02) includes fixes to the go command, linker,
runtime and the database/sql package. See the milestone on the issue
tracker for details:
List of changes; https://github.com/golang/go/issues?q=milestone%3AGo1.10.5
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 00ad8e7c5730f3c50ae2e548b47d1340202f72b2
Component: engine
@sw-pschmied originally post this in #38285
While looking through the Moby source code was found /proc/asound to be
shared with containers as read-only (as defined in
https://github.com/moby/moby/blob/master/oci/defaults.go#L128).
This can lead to two information leaks.
---
**Leak of media playback status of the host**
Steps to reproduce the issue:
- Listen to music/Play a YouTube video/Do anything else that involves
sound output
- Execute docker run --rm ubuntu:latest bash -c "sleep 7; cat
/proc/asound/card*/pcm*p/sub*/status | grep state | cut -d ' ' -f2 |
grep RUNNING || echo 'not running'"
- See that the containerized process is able to check whether someone
on the host is playing music as it prints RUNNING
- Stop the music output
- Execute the command again (The sleep is delaying the output because
information regarding playback status isn't propagated instantly)
- See that it outputs not running
**Describe the results you received:**
A containerized process is able to gather information on the playback
status of an audio device governed by the host. Therefore a process of a
container is able to check whether and what kind of user activity is
present on the host system. Also, this may indicate whether a container
runs on a desktop system or a server as media playback rarely happens on
server systems.
The description above is in regard to media playback - when examining
`/proc/asound/card*/pcm*c/sub*/status` (`pcm*c` instead of `pcm*p`) this
can also leak information regarding capturing sound, as in recording
audio or making calls on the host system.
Signed-off-by: Jonathan A. Schweder <jonathanschweder@gmail.com>
(cherry picked from commit 64e52ff3dbdb31adc0a9930b3ea74b04b0df8d86)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 5fffdb32261145b1178f571e25fbd71572769d58
Component: engine
Tibor Vass
Sebastiaan van Stijn
Brian Goff
Andrew Hsu
Sebastiaan van Stijn
Akihiro Suda
akolomentsev
Dimitris Mandalidis
Eli Uriegas
Jameson Hyde
Eli Uriegas
Madhu Venugopal
Tonis Tiigi
Michael Crosby
Iskander (Alex) Sharipov
Lifubang
Jonathan A. Schweder