diff options
author | Michael Opdenacker <michael.opdenacker@bootlin.com> | 2022-12-09 19:01:55 +0100 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2022-12-18 10:41:21 +0000 |
commit | 6846d4d00bc3a9d4e188ad9c8cfdf6e45cd1ba06 (patch) | |
tree | 6a59e9936ac9f2ca063d4fc8a5c4d9ecc9492769 /documentation/dev-manual/runtime-testing.rst | |
parent | 474e071608c7c1c97e9dafde810aef5630c716e7 (diff) | |
download | poky-6846d4d00bc3a9d4e188ad9c8cfdf6e45cd1ba06.tar.gz |
manuals: define proper numbered lists
Using "#." instead of "1.", "2.", "3.", etc.
(From yocto-docs rev: 11c2585acd0fa6c330702af2359ce5a9e47cde1f)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reported-by: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/dev-manual/runtime-testing.rst')
-rw-r--r-- | documentation/dev-manual/runtime-testing.rst | 28 |
1 files changed, 14 insertions, 14 deletions
diff --git a/documentation/dev-manual/runtime-testing.rst b/documentation/dev-manual/runtime-testing.rst index 88b3ed541b..36ccf746ee 100644 --- a/documentation/dev-manual/runtime-testing.rst +++ b/documentation/dev-manual/runtime-testing.rst | |||
@@ -84,25 +84,25 @@ In order to run tests, you need to do the following: | |||
84 | 84 | ||
85 | Once you start running the tests, the following happens: | 85 | Once you start running the tests, the following happens: |
86 | 86 | ||
87 | 1. A copy of the root filesystem is written to ``${WORKDIR}/testimage``. | 87 | #. A copy of the root filesystem is written to ``${WORKDIR}/testimage``. |
88 | 88 | ||
89 | 2. The image is booted under QEMU using the standard ``runqemu`` script. | 89 | #. The image is booted under QEMU using the standard ``runqemu`` script. |
90 | 90 | ||
91 | 3. A default timeout of 500 seconds occurs to allow for the boot process | 91 | #. A default timeout of 500 seconds occurs to allow for the boot process |
92 | to reach the login prompt. You can change the timeout period by | 92 | to reach the login prompt. You can change the timeout period by |
93 | setting | 93 | setting |
94 | :term:`TEST_QEMUBOOT_TIMEOUT` | 94 | :term:`TEST_QEMUBOOT_TIMEOUT` |
95 | in the ``local.conf`` file. | 95 | in the ``local.conf`` file. |
96 | 96 | ||
97 | 4. Once the boot process is reached and the login prompt appears, the | 97 | #. Once the boot process is reached and the login prompt appears, the |
98 | tests run. The full boot log is written to | 98 | tests run. The full boot log is written to |
99 | ``${WORKDIR}/testimage/qemu_boot_log``. | 99 | ``${WORKDIR}/testimage/qemu_boot_log``. |
100 | 100 | ||
101 | 5. Each test module loads in the order found in :term:`TEST_SUITES`. You can | 101 | #. Each test module loads in the order found in :term:`TEST_SUITES`. You can |
102 | find the full output of the commands run over SSH in | 102 | find the full output of the commands run over SSH in |
103 | ``${WORKDIR}/testimgage/ssh_target_log``. | 103 | ``${WORKDIR}/testimgage/ssh_target_log``. |
104 | 104 | ||
105 | 6. If no failures occur, the task running the tests ends successfully. | 105 | #. If no failures occur, the task running the tests ends successfully. |
106 | You can find the output from the ``unittest`` in the task log at | 106 | You can find the output from the ``unittest`` in the task log at |
107 | ``${WORKDIR}/temp/log.do_testimage``. | 107 | ``${WORKDIR}/temp/log.do_testimage``. |
108 | 108 | ||
@@ -117,13 +117,13 @@ For automated deployment, a "controller image" is installed onto the | |||
117 | hardware once as part of setup. Then, each time tests are to be run, the | 117 | hardware once as part of setup. Then, each time tests are to be run, the |
118 | following occurs: | 118 | following occurs: |
119 | 119 | ||
120 | 1. The controller image is booted into and used to write the image to be | 120 | #. The controller image is booted into and used to write the image to be |
121 | tested to a second partition. | 121 | tested to a second partition. |
122 | 122 | ||
123 | 2. The device is then rebooted using an external script that you need to | 123 | #. The device is then rebooted using an external script that you need to |
124 | provide. | 124 | provide. |
125 | 125 | ||
126 | 3. The device boots into the image to be tested. | 126 | #. The device boots into the image to be tested. |
127 | 127 | ||
128 | When running tests (independent of whether the image has been deployed | 128 | When running tests (independent of whether the image has been deployed |
129 | automatically or not), the device is expected to be connected to a | 129 | automatically or not), the device is expected to be connected to a |
@@ -188,11 +188,11 @@ not need any information in this section. You can skip down to the | |||
188 | If you did set :term:`TEST_TARGET` to "SystemdbootTarget", you also need to | 188 | If you did set :term:`TEST_TARGET` to "SystemdbootTarget", you also need to |
189 | perform a one-time setup of your controller image by doing the following: | 189 | perform a one-time setup of your controller image by doing the following: |
190 | 190 | ||
191 | 1. *Set EFI_PROVIDER:* Be sure that :term:`EFI_PROVIDER` is as follows:: | 191 | #. *Set EFI_PROVIDER:* Be sure that :term:`EFI_PROVIDER` is as follows:: |
192 | 192 | ||
193 | EFI_PROVIDER = "systemd-boot" | 193 | EFI_PROVIDER = "systemd-boot" |
194 | 194 | ||
195 | 2. *Build the controller image:* Build the ``core-image-testmaster`` image. | 195 | #. *Build the controller image:* Build the ``core-image-testmaster`` image. |
196 | The ``core-image-testmaster`` recipe is provided as an example for a | 196 | The ``core-image-testmaster`` recipe is provided as an example for a |
197 | "controller" image and you can customize the image recipe as you would | 197 | "controller" image and you can customize the image recipe as you would |
198 | any other recipe. | 198 | any other recipe. |
@@ -219,13 +219,13 @@ perform a one-time setup of your controller image by doing the following: | |||
219 | - Another partition labeled "testrootfs" where test images get | 219 | - Another partition labeled "testrootfs" where test images get |
220 | deployed. | 220 | deployed. |
221 | 221 | ||
222 | 3. *Install image:* Install the image that you just built on the target | 222 | #. *Install image:* Install the image that you just built on the target |
223 | system. | 223 | system. |
224 | 224 | ||
225 | The final thing you need to do when setting :term:`TEST_TARGET` to | 225 | The final thing you need to do when setting :term:`TEST_TARGET` to |
226 | "SystemdbootTarget" is to set up the test image: | 226 | "SystemdbootTarget" is to set up the test image: |
227 | 227 | ||
228 | 1. *Set up your local.conf file:* Make sure you have the following | 228 | #. *Set up your local.conf file:* Make sure you have the following |
229 | statements in your ``local.conf`` file:: | 229 | statements in your ``local.conf`` file:: |
230 | 230 | ||
231 | IMAGE_FSTYPES += "tar.gz" | 231 | IMAGE_FSTYPES += "tar.gz" |
@@ -233,7 +233,7 @@ The final thing you need to do when setting :term:`TEST_TARGET` to | |||
233 | TEST_TARGET = "SystemdbootTarget" | 233 | TEST_TARGET = "SystemdbootTarget" |
234 | TEST_TARGET_IP = "192.168.2.3" | 234 | TEST_TARGET_IP = "192.168.2.3" |
235 | 235 | ||
236 | 2. *Build your test image:* Use BitBake to build the image:: | 236 | #. *Build your test image:* Use BitBake to build the image:: |
237 | 237 | ||
238 | $ bitbake core-image-sato | 238 | $ bitbake core-image-sato |
239 | 239 | ||