For some shims (namely github.com/cpuguy83/containerd-shim-systemd-v1),
the shim cgroup test doesn't make sense since there is only a single
shim process for the entire node.
I use these integration tests to make sure the shim is compatible with
the runc shims and generally works as expected. This will let me skip
the shim cgroup test as there is no process for the shim to stick into
the cgroup... mostly.
There is a bootstrap process as well as a PTY copier proces which do use
the shim cgroup if provided, but the test is not able to check for
those (unless we enable tty on the test, which is a bit arbitrary and
not useful).
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
ForceRemoveAll was only used in tests/fuzzing, but added hcsshim as dependency
for the sys package. Moving this to integration/client makes the "sys" package
slightly more lightweight, and may help simplifying dependency-management.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This test tends to fail under Cirrus CI + Vagrant. Skipping for now
since running the test on GitHub Actions would be suffice.
Signed-off-by: Kazuyoshi Kato <katokazu@amazon.com>
The global &daemon{} object only gets an address assigned if you call
start() on it, which only gets called if you don't pass no-daemon. The
aftermath of this is that running the integration tests with no-daemon
just has them fail trying to create a client for containerd.
This change just assigns whatever address is passed to the binary even in
the no-daemon case so you can run the integration tests against an already
running containerd instance.
Signed-off-by: Daniel Canter <dcanter@microsoft.com>
The io/ioutil package has been deprecated as of Go 1.16, see
https://golang.org/doc/go1.16#ioutil. This commit replaces the existing
io/ioutil functions with their new definitions in io and os packages.
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
With the introduction of Windows Server 2022, some images have been updated
to support WS2022 in their manifest list. This commit updates the test images
accordingly.
Signed-off-by: Adelina Tuvenie <atuvenie@cloudbasesolutions.com>
Go 1.15.7 contained a security fix for CVE-2021-3115, which allowed arbitrary
code to be executed at build time when using cgo on Windows. This issue also
affects Unix users who have “.” listed explicitly in their PATH and are running
“go get” outside of a module or with module mode disabled.
This issue is not limited to the go command itself, and can also affect binaries
that use `os.Command`, `os.LookPath`, etc.
From the related blogpost (ttps://blog.golang.org/path-security):
> Are your own programs affected?
>
> If you use exec.LookPath or exec.Command in your own programs, you only need to
> be concerned if you (or your users) run your program in a directory with untrusted
> contents. If so, then a subprocess could be started using an executable from dot
> instead of from a system directory. (Again, using an executable from dot happens
> always on Windows and only with uncommon PATH settings on Unix.)
>
> If you are concerned, then we’ve published the more restricted variant of os/exec
> as golang.org/x/sys/execabs. You can use it in your program by simply replacing
This patch replaces all uses of `os/exec` with `golang.org/x/sys/execabs`. While
some uses of `os/exec` should not be problematic (e.g. part of tests), it is
probably good to be consistent, in case code gets moved around.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
While the issue hasn't been fixed in the kernel yet, we can workaround
the issue by not using overlayfs snapshotter.
The newly added step runs all tests that match /TestCheckpoint/.
So, TestCRWithImagePath has been renamed to match the regexp.
Fixes#3930.
Signed-off-by: Kazuyoshi Kato <katokazu@amazon.com>
This reduces the need to pull random images from docker.io, and should
greatly reduce the tendancy to hit their hourly rate-limit during
integration test runs.
TestImagePullSomePlatforms uses k8s.gcr.io/pause:3.2 so that it does not
see the content pulled by TestImagePullAllPlatforms. This image is
multi-arch, but not multi-os.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
