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>
This is done to make sure the script is working correctly in different
environments (distro and kernel versions). In addition, we can see in
test logs which kernel features are enabled.
Note that I didn't want to have a separate job for GHA CI, so I just
added this to the end of shellcheck one.
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>
golangci-lint-action v3 no longer installs golang itself, and the
version that comes with Ubuntu is not new/good enough.
Install go 1.17.x explicitly.
Introduce GO_VERSION environment variable to avoid duplication,
and use it instead of 1.x in other places, so that implicit go update
won't bring some unexpected failures.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
1. This valid warning is reported by shellcheck v0.8.0:
In tests/integration/helpers.bash line 38:
KERNEL_MINOR="${KERNEL_VERSION#$KERNEL_MAJOR.}"
^-----------^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns.
Did you mean:
KERNEL_MINOR="${KERNEL_VERSION#"$KERNEL_MAJOR".}"
Fix this.
2. These (invalid) warnings are also reported by the new version:
In tests/integration/events.bats line 13:
@test "events --stats" {
^-- SC2030 (info): Modification of status is local (to subshell caused by @bats test).
In tests/integration/events.bats line 41:
[ "$status" -eq 0 ]
^-----^ SC2031 (info): status was modified in a subshell. That change might be lost.
Basically, this is happening because shellcheck do not really track
the call tree and/or local variables. This is a known (and reported)
deficiency, and the alternative to disabling these warnings is moving
the code around, which is worse due to more changes in git history.
So we have to silence/disable these.
3. Update shellcheck to 0.8.0.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This adds a new GHA CI job which runs a few extra linters. This is only
done for pull requests, and should only warn about new code.
The justification is simple: we want more linters, but since this is not
a new project, adding a new linter meaning we have to fix all the
existing warnings. In some cases having all the warnings fixed is
difficult and takes time, plus it is usually a low priority task.
Therefore, we are stuck with inability to add new linters because we
can't fix all their warnings. Meanwhile, new pull requests add more
code which is not linted.
This is an attempt to break this vicious cycle. Let's enable godot
and revive for now and see how it is going.
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>
This implements cross-build for "make release", moving the build into a
container. This way we can support arm, arm64, ppc, and whatnot.
* script/seccomp.sh: separate out of script/release.sh, amend to support
cross-compile and save needed environment variables to a file.
* Dockerfile: add installing libseccomp from source, as this is needed
for release builds.
* script/release.sh: amend to support more architectures in addition to
the native build. Additional arches can be added by specifying
"-a <arch>" argument (can be specified multiple times), or
"make RELEASE_ARGS="-a arm64" release" if called via make.
All supported architectures can be enabled via "make releaseall".
* Makefile: move "release" target to "localrelease", add "release" and
"releaseall" targets to build via the Dockerfile. This is done because
most distros (including Fedora and openSUSE) lack cross-glibc, which is
needed to cross-compile libseccomp.
* Makefile: remove 'cross' and 'localcross' targets, as this is now done
by the release script.
* .github/workflows/validate.yum: amend the release CI job to cross-build
for supported architectures, remove cross job.
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>
The two exceptions I had to add to codespellrc are:
- CLOS (used by intelrtd);
- creat (syscall name used in tests/integration/testdata/seccomp_*.json).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Today we support the seccomp build tag only that is used by default.
However, we are not testing that compiling without any build tag works.
I found the CI didn't catch this when working on #2682, that the CI was
green but compilation without build tags was broken.
We test compilation without build tags only, compilation with the only
build tag supported is done extensively in other actions.
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>
It seems that golangci-lint didn't warn us about new lint errors that
were added after we enabled it, so just run the full thing and give us
all the errors on every PR run -- as long as we keep master lint-clean
it doesn't matter whether we set this or not.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Most of these were false positives or cases where we want to ignore the
lint, but the change to the BPF generation is actually useful.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Kir Kolyshkin