@@ -253,7 +253,9 @@ Tests map into the codebase as follows:
- The code for these tests resides in ``meta/lib/oeqa/runtime/cases/``.
- - You need to set the :term:`IMAGE_CLASSES` variable as follows::
+ - You need to set the :term:`IMAGE_CLASSES` variable as follows:
+
+ .. code-block:: bitbake
IMAGE_CLASSES += "testimage"
@@ -38,7 +38,9 @@ Adding package testing to your image is done in two steps:
#. Identify which of those ptest packages to add to your image.
First, in order to build all ptest packages, add the following line
-to a :term:`configuration file`::
+to a :term:`configuration file`:
+
+.. code-block:: bitbake
DISTRO_FEATURES:append = " ptest"
@@ -46,12 +48,16 @@ Note that this will cause all ptest packages to be built and packaged,
but will not add any of those packages to your image; that comes in
the next step. You can then add ptest packages to your image in one of two ways.
-#. If you want to add *all* of the generated ptest packages, add the line::
+#. If you want to add *all* of the generated ptest packages, add the line:
+
+ .. code-block:: bitbake
EXTRA_IMAGE_FEATURES += "ptest-pkgs"
#. On the other hand, if you want to add only a select few of the ptest
- packages, you can use some variation of::
+ packages, you can use some variation of:
+
+ .. code-block:: bitbake
IMAGE_INSTALL:append = " e2fsprogs-ptest zlib-ptest"
@@ -95,7 +101,9 @@ you need to prepare the recipes that build the packages you want to
test. Here is what you have to do for each recipe:
- *Be sure the recipe inherits the* :ref:`ref-classes-ptest` *class:*
- Include the following line in each recipe::
+ Include the following line in each recipe:
+
+ .. code-block:: bitbake
inherit ptest
@@ -148,7 +156,9 @@ test. Here is what you have to do for each recipe:
:term:`DEPENDS` and
:term:`RDEPENDS` variables in
your recipe in order for the package to meet the dependencies. Here
- is an example where the package has a runtime dependency on "make"::
+ is an example where the package has a runtime dependency on "make":
+
+ .. code-block:: bitbake
RDEPENDS:${PN}-ptest += "make"
@@ -169,7 +179,9 @@ test. Here is what you have to do for each recipe:
Regardless, you still must add a ``do_compile_ptest`` function to
build the test suite. Add a function similar to the following to your
- recipe::
+ recipe:
+
+ .. code-block:: bitbake
do_compile_ptest() {
oe_runmake buildtest-TESTS
@@ -95,7 +95,9 @@ This defaults to including a ``world`` build so, if other layers are added, it
would also run the tests for recipes in the additional layers. Different build
targets can be defined using the :term:`OEQA_REPRODUCIBLE_TEST_TARGET` variable
in ``local.conf``. For example, running reproducibility tests for only the
-``python3-numpy`` recipe can be done by setting::
+``python3-numpy`` recipe can be done by setting:
+
+.. code-block:: bitbake
OEQA_REPRODUCIBLE_TEST_TARGET = "python3-numpy"
@@ -150,7 +152,9 @@ Using :term:`OEQA_REPRODUCIBLE_TEST_* <OEQA_REPRODUCIBLE_TEST_LEAF_TARGETS>` var
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you want to test the reproducibility of a set of recipes, you can define
-:term:`OEQA_REPRODUCIBLE_TEST_LEAF_TARGETS`, in your local.conf::
+:term:`OEQA_REPRODUCIBLE_TEST_LEAF_TARGETS`, in your local.conf:
+
+.. code-block:: bitbake
OEQA_REPRODUCIBLE_TEST_LEAF_TARGETS = "my-recipe"
@@ -185,7 +185,9 @@ not need any information in this section. You can skip down to the
If you did set :term:`TEST_TARGET` to "SystemdbootTarget", you also need to
perform a one-time setup of your controller image by doing the following:
-#. *Set EFI_PROVIDER:* Be sure that :term:`EFI_PROVIDER` is as follows::
+#. *Set EFI_PROVIDER:* Be sure that :term:`EFI_PROVIDER` is as follows:
+
+ .. code-block:: bitbake
EFI_PROVIDER = "systemd-boot"
@@ -223,7 +225,9 @@ The final thing you need to do when setting :term:`TEST_TARGET` to
"SystemdbootTarget" is to set up the test image:
#. *Set up your local.conf file:* Make sure you have the following
- statements in your ``local.conf`` file::
+ statements in your ``local.conf`` file:
+
+ .. code-block:: bitbake
IMAGE_FSTYPES += "tar.gz"
IMAGE_CLASSES += "testimage"
@@ -244,7 +248,9 @@ power:
:term:`TEST_POWERCONTROL_EXTRA_ARGS` as a command that runs on the host
and does power cycling. The test code passes one argument to that
command: off, on or cycle (off then on). Here is an example that
- could appear in your ``local.conf`` file::
+ could appear in your ``local.conf`` file:
+
+ .. code-block:: bitbake
TEST_POWERCONTROL_CMD = "powercontrol.exp test 10.11.12.1 nuc1"
@@ -277,7 +283,9 @@ wish to experiment with automated hardware testing, you can use the
the required power action. This script requires either KDialog or Zenity
to be installed. To use this script, set the
:term:`TEST_POWERCONTROL_CMD`
-variable as follows::
+variable as follows:
+
+.. code-block:: bitbake
TEST_POWERCONTROL_CMD = "${COREBASE}/scripts/contrib/dialog-power-control"
@@ -299,7 +307,9 @@ connecting to a remote console server. Regardless of the case, the
command simply needs to connect to the serial console and forward that
connection to standard input and output as any normal terminal program
does. For example, to use the picocom terminal program on serial device
-``/dev/ttyUSB0`` at 115200bps, you would set the variable as follows::
+``/dev/ttyUSB0`` at 115200bps, you would set the variable as follows:
+
+.. code-block:: bitbake
TEST_SERIALCONTROL_CMD = "picocom /dev/ttyUSB0 -b 115200"
@@ -307,7 +317,9 @@ For local
devices where the serial port device disappears when the device reboots,
an additional "serdevtry" wrapper script is provided. To use this
wrapper, simply prefix the terminal command with
-``${COREBASE}/scripts/contrib/serdevtry``::
+``${COREBASE}/scripts/contrib/serdevtry``:
+
+.. code-block:: bitbake
TEST_SERIALCONTROL_CMD = "${COREBASE}/scripts/contrib/serdevtry picocom -b 115200 /dev/ttyUSB0"
@@ -319,7 +331,9 @@ You can start the tests automatically or manually:
- *Automatically running tests:* To run the tests automatically after the
OpenEmbedded build system successfully creates an image, first set the
:term:`TESTIMAGE_AUTO` variable to "1" in your ``local.conf`` file in the
- :term:`Build Directory`::
+ :term:`Build Directory`:
+
+ .. code-block:: bitbake
TESTIMAGE_AUTO = "1"
@@ -330,7 +344,9 @@ You can start the tests automatically or manually:
- *Manually running tests:* To manually run the tests, first globally
inherit the :ref:`ref-classes-testimage` class by editing your
- ``local.conf`` file::
+ ``local.conf`` file:
+
+ .. code-block:: bitbake
IMAGE_CLASSES += "testimage"
@@ -377,15 +393,21 @@ handling.
Here are some things to keep in mind when running tests:
-- The default tests for the image are defined as::
+- The default tests for the image are defined as:
+
+ .. code-block:: bitbake
DEFAULT_TEST_SUITES:pn-image = "ping ssh df connman syslog xorg scp vnc date rpm dnf dmesg"
-- Add your own test to the list of the by using the following::
+- Add your own test to the list of the by using the following:
+
+ .. code-block:: bitbake
TEST_SUITES:append = " mytest"
-- Run a specific list of tests as follows::
+- Run a specific list of tests as follows:
+
+ .. code-block:: bitbake
TEST_SUITES = "test1 test2 test3"
@@ -401,7 +423,9 @@ test execution off to a scheduler. You can only export tests that are
defined in :term:`TEST_SUITES`.
If your image is already built, make sure the following are set in your
-``local.conf`` file::
+``local.conf`` file:
+
+.. code-block:: bitbake
IMAGE_CLASSES += "testexport"
TEST_TARGET_IP = "IP-address-for-the-test-target"
@@ -427,7 +451,9 @@ You can now run the tests outside of the build environment::
hardware before you can run the tests.
Here is a complete example that shows IP addresses and uses the
-``core-image-sato`` image::
+``core-image-sato`` image:
+
+.. code-block:: bitbake
IMAGE_CLASSES += "testexport"
TEST_TARGET_IP = "192.168.7.2"
BitBake snippets here render as unhighlighted text. A reStructuredText literal block carries no language, and Sphinx falls back to a default that cannot recognise BitBake metadata. Pygments 2.21 added a BitBake lexer, so tag these 27 blocks explicitly. Variable names, assignment operators, override chains, expansions and shell or Python task bodies are then highlighted. Blocks that only look like BitBake are left alone, as are blocks already tagged "none" where the content is deliberately unhighlighted. AI-Generated: codex/claude-opus 5 (xhigh) Signed-off-by: Trevor Woerner <twoerner@gmail.com> --- documentation/test-manual/intro.rst | 4 +- documentation/test-manual/ptest.rst | 24 ++++++--- .../test-manual/reproducible-builds.rst | 8 ++- documentation/test-manual/runtime-testing.rst | 52 ++++++++++++++----- 4 files changed, 66 insertions(+), 22 deletions(-)