2018-10-09 15:37:00 +03:00
The extended testsuite only works with UID=0. It contains of several
2012-05-25 20:44:42 +04:00
subdirectories named "test/TEST-??-*", which are run one by one.
To run the extended testsuite do the following:
2018-10-09 15:37:00 +03:00
$ ninja -C build # Avoid building anything as root later
$ sudo test/run-integration-tests.sh
ninja: Entering directory `/home/zbyszek/src/systemd/build'
ninja: no work to do.
--x-- Running TEST-01-BASIC --x--
2020-11-17 23:39:37 +03:00
+ make -C TEST-01-BASIC clean setup run
2018-10-09 15:37:00 +03:00
make: Entering directory '/home/zbyszek/src/systemd/test/TEST-01-BASIC'
2020-03-25 15:15:37 +03:00
TEST-01-BASIC CLEANUP: Basic systemd setup
TEST-01-BASIC SETUP: Basic systemd setup
2012-05-25 20:44:42 +04:00
...
2020-03-25 15:15:37 +03:00
TEST-01-BASIC RUN: Basic systemd setup [OK]
2018-10-09 15:37:00 +03:00
make: Leaving directory '/home/zbyszek/src/systemd/test/TEST-01-BASIC'
--x-- Result of TEST-01-BASIC: 0 --x--
--x-- Running TEST-02-CRYPTSETUP --x--
2020-11-17 23:39:37 +03:00
+ make -C TEST-02-CRYPTSETUP clean setup run
2012-05-25 20:44:42 +04:00
If one of the tests fails, then $subdir/test.log contains the log file of
the test.
2018-10-09 15:37:00 +03:00
To run just one of the cases:
2012-05-25 20:44:42 +04:00
2018-10-09 15:37:00 +03:00
$ sudo make -C test/TEST-01-BASIC clean setup run
2012-05-25 20:44:42 +04:00
2018-10-09 15:37:00 +03:00
Specifying the build directory
==============================
2013-12-08 03:01:53 +04:00
2018-10-09 15:37:00 +03:00
If the build directory is not detected automatically, it can be specified
with BUILD_DIR=:
2012-05-25 20:44:42 +04:00
2018-10-09 15:37:00 +03:00
$ sudo BUILD_DIR=some-other-build/ test/run-integration-tests
2012-05-25 20:44:42 +04:00
2018-10-09 15:37:00 +03:00
or
2012-05-25 20:44:42 +04:00
2018-10-09 15:37:00 +03:00
$ sudo make -C test/TEST-01-BASIC BUILD_DIR=../../some-other-build/ ...
2013-12-08 03:01:53 +04:00
2018-10-09 15:37:00 +03:00
Note that in the second case, the path is relative to the test case directory.
An absolute path may also be used in both cases.
Configuration variables
=======================
2019-03-16 20:32:38 +03:00
TEST_NO_QEMU=1
Don't run tests under QEMU
2018-10-09 15:37:00 +03:00
2020-12-26 23:11:55 +03:00
TEST_QEMU_ONLY=1
Run only tests that require QEMU
2019-03-16 20:32:38 +03:00
TEST_NO_NSPAWN=1
Don't run tests under systemd-nspawn
2013-12-08 03:01:53 +04:00
2020-12-31 20:29:58 +03:00
TEST_PREFER_NSPAWN=1
Run all tests that do not require qemu under systemd-nspawn
2019-03-16 20:32:38 +03:00
TEST_NO_KVM=1
2019-11-30 17:33:59 +03:00
Disable QEMU KVM auto-detection (may be necessary when you're trying to run the
2019-03-16 20:32:38 +03:00
*vanilla* QEMU and have both qemu and qemu-kvm installed)
2019-09-27 00:29:38 +03:00
TEST_NESTED_KVM=1
Allow tests to run with nested KVM. By default, the testsuite disables
nested KVM if the host machine already runs under KVM. Setting this
variable disables such checks
2019-03-16 20:32:38 +03:00
QEMU_MEM=512M
Configure amount of memory for QEMU VMs (defaults to 512M)
QEMU_SMP=1
Configure number of CPUs for QEMU VMs (defaults to 1)
KERNEL_APPEND='...'
Append additional parameters to the kernel command line
NSPAWN_ARGUMENTS='...'
Specify additional arguments for systemd-nspawn
QEMU_TIMEOUT=infinity
Set a timeout for tests under QEMU (defaults to infinity)
NSPAWN_TIMEOUT=infinity
Set a timeout for tests under systemd-nspawn (defaults to infinity)
INTERACTIVE_DEBUG=1
Configure the machine to be more *user-friendly* for interactive debuggung
(e.g. by setting a usable default terminal, suppressing the shutdown after
the test, etc.)
2018-10-09 15:37:00 +03:00
The kernel and initramfs can be specified with $KERNEL_BIN and $INITRD.
(Fedora's or Debian's default kernel path and initramfs are used by default)
2013-12-08 03:01:53 +04:00
A script will try to find your QEMU binary. If you want to specify a different
2018-10-09 15:37:00 +03:00
one with $QEMU_BIN.
Debugging the qemu image
========================
If you want to log in the testsuite virtual machine, you can specify additional
kernel command line parameter with $KERNEL_APPEND and then log in as root.
$ sudo make -C test/TEST-01-BASIC KERNEL_APPEND="systemd.unit=multi-user.target" run
2013-12-08 03:01:53 +04:00
2018-10-09 15:37:00 +03:00
Root password is empty.
2019-10-02 11:16:01 +03:00
Ubuntu CI
=========
New PR submitted to the project are run through regression tests, and one set
of those is the 'autopkgtest' runs for several different architectures, called
'Ubuntu CI'. Part of that testing is to run all these tests. Sometimes these
2020-07-10 23:13:31 +03:00
tests are temporarily deny-listed from running in the 'autopkgtest' tests while
2019-10-02 11:16:01 +03:00
debugging a flaky test; that is done by creating a file in the test directory
2020-07-10 23:13:31 +03:00
named 'deny-list-ubuntu-ci', for example to prevent the TEST-01-BASIC test from
2019-10-02 11:16:01 +03:00
running in the 'autopkgtest' runs, create the file
2020-07-10 23:13:31 +03:00
'TEST-01-BASIC/deny-list-ubuntu-ci'.
2019-10-02 11:16:01 +03:00
2020-07-10 23:13:31 +03:00
The tests may be disabled only for specific archs, by creating a deny-list file
2019-10-02 11:16:01 +03:00
with the arch name at the end, e.g.
2020-07-10 23:13:31 +03:00
'TEST-01-BASIC/deny-list-ubuntu-ci-arm64' to disable the TEST-01-BASIC test
2019-10-02 11:16:01 +03:00
only on test runs for the 'arm64' architecture.
Note the arch naming is not from 'uname -m', it is Debian arch names:
https://wiki.debian.org/ArchitectureSpecificsMemo
2020-07-10 23:13:31 +03:00
For PRs that fix a currently deny-listed test, the PR should include removal
of the deny-list file.
2020-10-16 19:51:58 +03:00
In case a test fails, the full set of artifacts, including the journal of the
failed run, can be downloaded from the artifacts.tar.gz archive which will be
reachable in the same URL parent directory as the logs.gz that gets linked on
the Github CI status.
To add new dependencies or new binaries to the packages used during the tests,
a merge request can be sent to: https://salsa.debian.org/systemd-team/systemd
targeting the 'upstream-ci' branch.
2021-01-05 17:05:15 +03:00
The cloud-side infrastructure, that is hooked into the Github interface, is
located at:
https://git.launchpad.net/autopkgtest-cloud/