It is one of our target platforms.
Cc: Adrian Reber <areber@redhat.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Acked-by: Adrian Reber <areber@redhat.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Sometimes we see errors like this:
criu/cr-restore.gcda:Merge mismatch for function 106
It proabably means that this gcda file was corrupted. According to the
gcc man page, the -fprofile-update=atomic should fix this problem.
v2: this options appered in gcc7, so we need to install it.
Reported-by: Mr Travis CI
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
The x86_64 job is the one we run inside Docker (as opposed to 'local',
which runs on the host). Let's update this to use Ubuntu Zesty, and
since it has clang-4 (unlike the 'local' one) it makes sense to add
a clang build.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
We have to use "debian.jessie" instead of "ubuntu.xenial" because
qemu-s390x-static can only run z900 instructions and Ubuntu is
built with a more recent architecture level set.
We first enable only gcc because there are still some issues with clang.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
v2: Use the devicemapper storage driver for docker containers to
run more tests. AUFS doesn't support file handles, so a few tests
(e.g. inotify00 can't be run).
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
For now, it's done for local builds only (i.e. no per-arch Docker
builds yet). The reason is, it's easier to play with ccache when
the compiles are (relatively) fast.
Performance: there is 2x to 3x improvement in build speeds for
ideal cases (same code, hot cache), but the absolute savings
are negligible (example: 7 seconds instead of 23).
Note that ccache is not compatible with gcov, so we only enable it
for non-gcov build (which happens to be the one with clang).
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
"zdtm.py run -a" doesn't work on Alpine:
find: unrecognized: -executable
So run zdtm/static/env00 for now to be sure that
it is not broken at all.
travis-ci: success for travis: execute tests on Alpine
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
With the recent patches, criu is finally compileable with
clang for all architectures. To keep it that way, we need
Travis to test that on a regular basis.
The downside is, Travis build time is increased about 2x.
travis-ci: success for travis: enable arm/arm64/ppc builds with clang
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
1. GCOV=0 is wrong, it should be left unset (or set to empty value)
2. GCOV=1 only makes sense for TR_ARCH=local, others are not using it
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Move GCOV to travis environment, so now we can change it easily
on a per-build basis.
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
I suggest to add support for coveralls.io.
It can't show all coverage, as we don't run all tests on travis,
but still everyone who forked CRIU can see instant coverage of
his Travis build. As a nice feature, it will show code cover
increasing/decreasing just after you push a commit - which
could give you a nice hint about content of a new tests.
For this feature, we need to build CRIU with `make GCOV=1`,
which adds --coverage and disables optimizations.
The resulting report looks like this:
https://coveralls.io/builds/6439346
I was thinking about codecov.io also, but it has fewer community,
less fixed issues on github - so I choose this service.
Just a random fun fact:
file-ids.c covered completely on tests, except -ENOMEM return.
Maybe it worth to run fault injections tests on Travis.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
qemu-static from ubuntu/xenial contains a required fix
and now we can execute compilation for ppc64le in travis.
v2: rebase on criu-dev
v3: set QEMU_CPU=POWER8 to avoid segfaults of qemu-ppc64le-static
> > By default, both qemu and gcc5 produce code on ppc64el which will run on
> > POWER7 platform. However, in debian gcc build instruction, gcc is explicitly
> > built to produce code for POWER8 platform, which, obviously has additional
> > instructions.
v4: use ubuntu:trusty. xenial and wily has a bug:
Processing triggers for libc-bin (2.21-0ubuntu4.1) ...
/sbin/ldconfig.real: 5: /sbin/ldconfig.real: Syntax error: ")" unexpected
/sbin/ldconfig.real: 5: /sbin/ldconfig.real: Syntax error: ")" unexpected
v5: arm, x86, aarch64 were removed by mistake
Signed-off-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
We can't execute userns tests, because a kernel is too old there.
Signed-off-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Otherwise a default actions for this step will be executed:
$ ./configure && make && make test
/home/travis/build.sh: line 45: ./configure: No such file or directory
Signed-off-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
precise's libc headers are extremly old and don't define SYS_*. trusty's
do, so let's run the travis tests there.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Travis CI is configured by adding a file named .travis.yml, which is a
YAML format text file, to the root directory of the GitHub
repository.[5]
Travis CI automatically detects when a commit has been made and pushed
to a GitHub repository that is using Travis CI, and each time this
happens, it will try to build the project and run tests.
""" https://en.wikipedia.org/wiki/Travis_CI
Currently Travis CI builds criu for x86_64 and ARM
v2: move travis-ci.sh in scripts
v3: fix path to the script in the script
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
