It doesn't matter whether static or dynamic linking is used, runc
always needs libcontainer/nsenter, which is written in C and thus
requires cgo. Same is true for libcontainer/integration.
In addition, contrib/pkg/seccompagent also needs cgo (if seccomp build
tag is set), as it need to be linked against libseccomp C library.
By default, cgo is disabled when cross-compiling, meaning that
CGO_ENABLED=1 has to be set explicitly in such cases.
In all other cases (e.g. other contrib binaries) we do not need cgo.
Remove CGO_ENABLED=1 from GO_BUILD_STATIC (as it does not have anything
to do with static linking), and add it to all targets that require it.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Since the recent bump of actions/setup-go to v3 (commit
9d2268b9db), specifying "stable:" is no longer needed
when we want to try a beta or rc version of Go.
Remove it.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Require go 1.17 from now on, since go 1.16 is no longer supported.
Drop go1.16 compatibility.
NOTE we also have to install go 1.18 from Vagrantfile, because
Fedora 35 comes with Go 1.16.x which can't be used.
Note the changes to go.mod and vendor are due to
https://go.dev/doc/go1.17#tools
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
As reported in [1], in a case where read-only fuse (sshfs) mount
is used as a volume without specifying ro flag, the kernel fails
to remount it (when adding various flags such as nosuid and nodev),
returning EPERM.
Here's the relevant strace line:
> [pid 333966] mount("/tmp/bats-run-PRVfWc/runc.RbNv8g/bundle/mnt", "/proc/self/fd/7", 0xc0001e9164, MS_NOSUID|MS_NODEV|MS_REMOUNT|MS_BIND|MS_REC, NULL) = -1 EPERM (Operation not permitted)
I was not able to reproduce it with other read-only mounts as the source
(tried tmpfs, read-only bind mount, and an ext2 mount), so somehow this
might be specific to fuse.
The fix is to check whether the source has RDONLY flag, and retry the
remount with this flag added.
A test case (which was kind of hard to write) is added, and it fails
without the fix. Note that rootless user need to be able to ssh to
rootless@localhost in order to sshfs to work -- amend setup scripts
to make it work, and skip the test if the setup is not working.
[1] https://github.com/containers/podman/issues/12205
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Go 1.15 is not supported since Go 1.17 release (16 Aug 2021), and some
packages that we use already require Go 1.16+ (notably,
github.com/cilium/ebpf v0.7.0).
Let's require Go 1.16+.
Remove Go version requirement from README when describing dependencies,
since it is no longer needed:
$ GO=go1.15.15 make vendor
go1.15.15 mod tidy
go mod tidy: go.mod file indicates go 1.16, but maximum supported version is 1.15
make: *** [Makefile:141: vendor] Error 1
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Jobs verify/compile-buildtags and verify/deps relied on whatever Go
version is available from the Ubuntu-20.04 image, which seems to be
1.15.x).
Job test/cross-i386 was installing whatever Go version is considered to
be the default one by actions/setup-go@v2, which seems to be go 1.15.15
at the moment.
Fix all three jobs to install Go 1.x (which should translate to latest
stable Go version, i.e. 1.17.2 as of now).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
As commits 120f74060 and a58718013 were added independently,
criu-dev go version was left at 1.16.x. Fix this.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Treat warning as errors only in the CI. We can enforce it in the source
code (like setting CFLAGS in libcontainer/nsenter/nsenter.go), but that
can force other downstream to patch the code if thei C compiler produces
warnings. For that reason, we do it only on the CI.
Todays CGO warnings are quite hidden in the CI (only shown for the
compilation step, that is collapsed) and CI is green anyways. With this
patch, CI fails if a warning is introduced.
Signed-off-by: Rodrigo Campos <rodrigo@kinvolk.io>
Add testing against criu-dev branch instead of a released version
(happens to be criu v3.15 at the moment), to check how it works.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This simplifies and optimizes getting container images used for tests.
Currently, we have three different ways of getting images:
1. (for hello-world) the image is in this repo under tests/integration/testdata.
2. (for busybox) download it from github (the repo that is used for
preparing official Docker image) using curl.
3. (for debian) download from Docker hub, using skopeo and umoci.
To further complicate things, we have to do this downloading in multiple
scenarios (at least 4): locally, in github CI, from Dockefile, inside a
Vagrant VM. For each scenario, we have to install skopeo and umoci, and
those two are not yet universally available for all the distros that we
use.
Yet another complication is those images are used for tests/integration
(bats-driven tests) as well as for libcontainer/integration (go tests).
The tests in libcontainer/integration rely on busybox being available
from /busybox, and the bats tests just download the images to a
temporary location during every run.
It is also hard to support CI for other architectures, because all
the machinery for preparing images is so complicated.
This commit is an attempt to simplify and optimize getting images,
mostly by getting rid of skopeo and umoci dependencies, but also
by moving the download logic into one small shell script, which
is used from all the places.
Benefits:
- images (if not present) are only downloaded once;
- same images are used for both kind of tests (go and bats);
- same images are used for local and inside-docker tests
(because source directory is mounted into container);
- the download logic is located within 1 simple shell script.
[v2: fix eval; more doc to get-images; print URL if curl failed]
[v3: use "slim" debian, twice as small]
[v4: fix not using $image in setup_bundle]
[v5: don't remove TESTDATA from helpers.bash]
[v6: add i386 support]
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
The fedora job usually completes within 15-16 minutes,
and the centos-7 one needs 7-8 minutes.
Set the timeouts to twice those values.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Github Actions execution environments lack tty, which is needed for
integration tests. We have used script utility before to provide a fake
tty, but it appears to be buggy on CentOS 7.
Since we use ssh anyway to access Vagant VM, add -tt to forcefully
allocate a tty.
Apparently, neither "TERM=xterm" nor "stty size" is needed for
any tests to work, so remove those, too.
Finally, unit tests do not need a terminal, so remove the "script"
from those.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This is Ubuntu 20.04 so cgroup v1 testing only :(
The upside is, it's pretty fast (currently all the tests finish
within 5 minutes).
rootless tests take longer time so we run them in parallel
with non-rootless ones. Also, to balance the time, we run
unit tests when rootless is not set. IOW, 'rootless' in job
name means it's only rootless integration tests, and no rootless
means it's unit tests, integration tests with fs driver, and
integration tests with systemd driver.
Note, `script` is used to run integration tests to provide a tty
(which by default is not available on gh actions).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Kir Kolyshkin