From df02dd8c6552ff9e798ec667f7ed9db422b23716 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Thu, 27 Mar 2014 07:16:04 -0600 Subject: dev-manual: WIP for YOCTO #5554. (From yocto-docs rev: 00ecee108d87b5c1044e7b6df702e59f0332035f) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- .../dev-manual/dev-manual-common-tasks.xml | 171 +++++++++++++-------- 1 file changed, 111 insertions(+), 60 deletions(-) (limited to 'documentation/dev-manual') diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml index c11df717d3..6fa850d4ed 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/documentation/dev-manual/dev-manual-common-tasks.xml @@ -5588,77 +5588,116 @@ The OpenEmbedded build system makes available a series of automated tests for images to verify runtime functionality. - - Currently, there is only support for running these tests - under QEMU. - - These tests are written in Python making use of the + You can run these tests on either QEMU or actual target hardware. + Tests are written in Python making use of the unittest module, and the majority of them run commands on the target system over SSH. This section describes how you set up the environment to use these tests, run available tests, and write and add your own tests. -
+
Enabling Tests - In order to run tests, you need to do the following: - - Set up to avoid interaction - with sudo for networking: - To accomplish this, you must do one of the - following: - - Add - NOPASSWD for your user - in /etc/sudoers either for - ALL commands or just for - runqemu-ifup. - You must provide the full path as that can - change if you are using multiple clones of the - source repository. - - On some distributions, you also need to - comment out "Defaults requiretty" in - /etc/sudoers. - - Manually configure a tap interface - for your system. - Run as root the script in - scripts/runqemu-gen-tapdevs, - which should generate a list of tap devices. - This is the option typically chosen for - Autobuilder-type environments. - - - Set the - DISPLAY variable: - You need to set this variable so that you have an X - server available (e.g. start - vncserver for a headless machine). - - Be sure your host's firewall - accepts incoming connections from - 192.168.7.0/24: - Some of the tests (in particular smart tests) start an - HTTP server on a random high number port, which is - used to serve files to the target. - The smart module serves - ${DEPLOY_DIR}/rpm so it can run - smart channel commands. That means your host's firewall - must accept incoming connections from 192.168.7.0/24, - which is the default IP range used for tap devices - by runqemu. - + Depending on whether you are planning on running tests using + QEMU or on running them on the hardware, you have to take + different steps to enable the tests. + See the following subsections for information on how to + enable both types of tests. - - Regardless of how you initiate the tests, if you built your - image using rm_work, - most of the tests will fail with errors because they rely on - ${WORKDIR}/installed_pkgs.txt. - +
+ QEMU + + + In order to run tests, you need to do the following: + + Set up to avoid interaction + with sudo for networking: + To accomplish this, you must do one of the + following: + + Add + NOPASSWD for your user + in /etc/sudoers either for + ALL commands or just for + runqemu-ifup. + You must provide the full path as that can + change if you are using multiple clones of the + source repository. + + On some distributions, you also need to + comment out "Defaults requiretty" in + /etc/sudoers. + + Manually configure a tap interface + for your system. + Run as root the script in + scripts/runqemu-gen-tapdevs, + which should generate a list of tap devices. + This is the option typically chosen for + Autobuilder-type environments. + + + Set the + DISPLAY variable: + You need to set this variable so that you have an X + server available (e.g. start + vncserver for a headless machine). + + Be sure your host's firewall + accepts incoming connections from + 192.168.7.0/24: + Some of the tests (in particular smart tests) start an + HTTP server on a random high number port, which is + used to serve files to the target. + The smart module serves + ${DEPLOY_DIR}/rpm so it can run + smart channel commands. That means your host's firewall + must accept incoming connections from 192.168.7.0/24, + which is the default IP range used for tap devices + by runqemu. + + + + + Regardless of how you initiate the tests, if you built your + image using rm_work, + most of the tests will fail with errors because they rely on + ${WORKDIR}/installed_pkgs.txt. + +
+ +
+ Hardware + + + This section needs the information specific to enabling + tests to run on actual hardware. + Here are some developer notes: + + + Paul says this "If you have deployed the image yourself, + you can manually boot it, you know the IP address + it will show up under, and SSH is installed with no + password, then you can now run tests on any real + machine." + + + TEST_TARGET variable needs to equal + "simpleremote" + + + Here are some notes from the patch - "The remote machine + must be up with network and ssh and you need to set + TEST_TARGET_IP with the IP address + of the remote machine (it can still be a qemu instance that + was manually started) + + + +
@@ -5677,6 +5716,18 @@ Build Directory: TEST_IMAGE = "1" + + Next, also in the local.conf, set the + TEST_TARGET variable to + "simpleremote" if you want to run tests on real hardware or + set it to "qemu" if you want to run tests using QEMU. + file: + + TEST_TARGET = "simpleremote" + + or + + TEST_TARGET = "qemu" Next, build your image. If the image successfully builds, the tests will be -- cgit v1.2.3-54-g00ecf