summaryrefslogtreecommitdiffstats
path: root/documentation
diff options
context:
space:
mode:
authorMark Morton <Mark.Morton@windriver.com>2020-06-16 14:14:50 -0700
committerRichard Purdie <richard.purdie@linuxfoundation.org>2020-06-17 16:45:36 +0100
commit444666faa47186d30d222eb0ebe4a25f1649f6e5 (patch)
tree8b015da9e69d16981f58fe42bdbe0bb96ad5d4e8 /documentation
parent04118df8b08c19f3c9872d67aaa96cb5d183a0f5 (diff)
downloadpoky-444666faa47186d30d222eb0ebe4a25f1649f6e5.tar.gz
New source files and Makefile update for Test Manual
(From yocto-docs rev: d7cff640569a5772f3c366b4136762628fca534d) Signed-off-by: Mark Morton <mark.morton@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation')
-rw-r--r--documentation/Makefile10
-rw-r--r--documentation/test-manual/figures/ab-test-cluster.pngbin0 -> 18684 bytes
-rw-r--r--documentation/test-manual/figures/test-manual-title.pngbin0 -> 15382 bytes
-rw-r--r--documentation/test-manual/test-manual-customization.xsl27
-rw-r--r--documentation/test-manual/test-manual-intro.xml634
-rw-r--r--documentation/test-manual/test-manual-style.css989
-rw-r--r--documentation/test-manual/test-manual-test-process.xml109
-rw-r--r--documentation/test-manual/test-manual-understand-autobuilder.xml312
-rwxr-xr-xdocumentation/test-manual/test-manual.xml103
9 files changed, 2184 insertions, 0 deletions
diff --git a/documentation/Makefile b/documentation/Makefile
index 2f7292214f..6a369637f5 100644
--- a/documentation/Makefile
+++ b/documentation/Makefile
@@ -358,6 +358,16 @@ STYLESHEET = $(DOC)/*.css
358endif 358endif
359 359
360 360
361ifeq ($(DOC),test-manual)
362XSLTOPTS = --xinclude
363ALLPREQ = html tarball
364TARFILES = test-manual.html test-manual-style.css \
365 figures/test-manual-title.png figures/ab-test-cluster.png
366MANUALS = $(DOC)/$(DOC).html
367FIGURES = figures
368STYLESHEET = $(DOC)/*.css
369endif
370
361## 371##
362# These URI should be rewritten by your distribution's xml catalog to 372# These URI should be rewritten by your distribution's xml catalog to
363# match your locally installed XSL stylesheets. 373# match your locally installed XSL stylesheets.
diff --git a/documentation/test-manual/figures/ab-test-cluster.png b/documentation/test-manual/figures/ab-test-cluster.png
new file mode 100644
index 0000000000..6a6a7882b4
--- /dev/null
+++ b/documentation/test-manual/figures/ab-test-cluster.png
Binary files differ
diff --git a/documentation/test-manual/figures/test-manual-title.png b/documentation/test-manual/figures/test-manual-title.png
new file mode 100644
index 0000000000..c709cb9d09
--- /dev/null
+++ b/documentation/test-manual/figures/test-manual-title.png
Binary files differ
diff --git a/documentation/test-manual/test-manual-customization.xsl b/documentation/test-manual/test-manual-customization.xsl
new file mode 100644
index 0000000000..6e437d4826
--- /dev/null
+++ b/documentation/test-manual/test-manual-customization.xsl
@@ -0,0 +1,27 @@
1<?xml version='1.0'?>
2<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
3
4 <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
5
6<!--
7
8 <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
9
10 <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
11
12-->
13
14 <xsl:include href="../template/permalinks.xsl"/>
15 <xsl:include href="../template/section.title.xsl"/>
16 <xsl:include href="../template/component.title.xsl"/>
17 <xsl:include href="../template/division.title.xsl"/>
18 <xsl:include href="../template/formal.object.heading.xsl"/>
19
20 <xsl:param name="html.stylesheet" select="'test-manual-style.css'" />
21 <xsl:param name="chapter.autolabel" select="1" />
22 <xsl:param name="appendix.autolabel" select="A" />
23 <xsl:param name="section.autolabel" select="1" />
24 <xsl:param name="section.label.includes.component.label" select="1" />
25 <xsl:param name="generate.id.attributes" select="1" />
26
27</xsl:stylesheet>
diff --git a/documentation/test-manual/test-manual-intro.xml b/documentation/test-manual/test-manual-intro.xml
new file mode 100644
index 0000000000..5e9def894e
--- /dev/null
+++ b/documentation/test-manual/test-manual-intro.xml
@@ -0,0 +1,634 @@
1<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
2"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
3[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
4
5<chapter id='test-manual-intro'>
6
7<title>The Yocto Project Test Environment Manual</title>
8 <section id='test-welcome'>
9 <title>Welcome</title>
10
11 <para> Welcome to the Yocto Project Test Environment Manual! This manual is a work in
12 progress. The manual contains information about the testing environment used by the
13 Yocto Project to make sure each major and minor release works as intended. All the
14 project’s testing infrastructure and processes are publicly visible and available so
15 that the community can see what testing is being performed, how it’s being done and the
16 current status of the tests and the project at any given time. It is intended that Other
17 organizations can leverage off the process and testing environment used by the Yocto
18 Project to create their own automated, production test environment, building upon the
19 foundations from the project core. </para>
20
21 <para> Currently, the Yocto Project Test Environment Manual has no projected release date.
22 This manual is a work-in-progress and is being initially loaded with information from
23 the <ulink url="">README</ulink> files and notes from key engineers: <itemizedlist>
24 <listitem>
25 <para>
26 <emphasis><filename>yocto-autobuilder2</filename>:</emphasis> This <ulink
27 url="http://git.yoctoproject.org/clean/cgit.cgi/yocto-autobuilder2/tree/README.md"
28 ><filename>README.md</filename></ulink> is the main README which
29 detials how to set up the Yocto Project Autobuilder. The
30 <filename>yocto-autobuilder2</filename> repository represents the Yocto
31 Project's console UI plugin to Buildbot and the configuration necessary to
32 configure Buildbot to perform the testing the project requires. </para>
33 </listitem>
34 <listitem>
35 <para>
36 <emphasis><filename>yocto-autobuilder-helper</filename>:</emphasis> This
37 <ulink
38 url="http://git.yoctoproject.org/clean/cgit.cgi/yocto-autobuilder-helper/tree/README"
39 ><filename>README</filename></ulink> and repository contains Yocto
40 Project Autobuilder Helper scripts and configuration. The
41 <filename>yocto-autobuilder-helper</filename> repository contains the
42 "glue" logic that defines which tests to run and how to run them. As a
43 result, it can be used by any Continuous Improvement (CI) system to run
44 builds, support getting the correct code revisions, configure builds and
45 layers, run builds, and collect results. The code is independent of any CI
46 system, which means the code can work Buildbot, Jenkins, or others. This
47 repository has a branch per release of the project defining the tests to run
48 on a per release basis.</para>
49 </listitem>
50 </itemizedlist>
51 </para>
52 </section>
53
54 <section id='test-yocto-project-autobuilder-overview'>
55 <title>Yocto Project Autobuilder Overview</title>
56
57 <para>The Yocto Project Autobuilder collectively refers to the software, tools, scripts, and
58 procedures used by the Yocto Project to test released software across supported hardware
59 in an automated and regular fashion. Basically, during the development of a Yocto
60 Project release, the Autobuilder tests if things work. The Autobuilder builds all test
61 targets and runs all the tests. </para>
62
63 <para>The Yocto Project uses now uses standard upstream <ulink
64 url="https://docs.buildbot.net/0.9.15.post1/">Buildbot</ulink> (version 9) to drive
65 its integration and testing. Buildbot Nine has a plug-in interface that the Yocto
66 Project customizes using code from the <filename>yocto-autobuilder2</filename>
67 repository, adding its own console UI plugin. The resulting UI plug-in allows you to
68 visualize builds in a way suited to the project's needs.</para>
69
70 <para>A <filename>helper</filename> layer provides configuration and job management through
71 scripts found in the <filename>yocto-autobuilder-helper</filename> repository. The
72 <filename>helper</filename> layer contains the bulk of the build configuration
73 information and is release-specific, which makes it highly customizable on a per-project
74 basis. The layer is CI system-agnostic and contains a number of Helper scripts that can
75 generate build configurations from simple JSON files. <note>
76 <para>The project uses Buildbot for historical reasons but also because many of the
77 project developers have knowledge of python. It is possible to use the outer
78 layers from another Continuous Integration (CI) system such as <ulink
79 url="https://en.wikipedia.org/wiki/Jenkins_(software)">Jenkins</ulink>
80 instead of Buildbot. </para>
81 </note>
82 </para>
83
84 <para> The following figure shows the Yocto Project Autobuilder stack with a topology that
85 includes a controller and a cluster of workers: <imagedata
86 fileref="figures/ab-test-cluster.png" width="4.6in" depth="4.35in" align="center"
87 scalefit="1"/>
88 </para>
89 </section>
90
91 <section id='test-project-tests'>
92 <title>Yocto Project Tests - Types of Testing Overview</title>
93
94 <para>The Autobuilder tests different elements of the project by using thefollowing types of
95 tests: <itemizedlist>
96 <listitem>
97 <para>
98 <emphasis>Build Testing:</emphasis> Tests whether specific configurations
99 build by varying <ulink url="&YOCTO_DOCS_REF_URL;#var-MACHINE"
100 ><filename>MACHINE</filename></ulink>, <ulink
101 url="&YOCTO_DOCS_REF_URL;#var-DISTRO"
102 ><filename>DISTRO</filename></ulink>, other configuration options, and
103 the specific target images being built (or world). Used to trigger builds of
104 all the different test configurations on the Autobuilder. Builds usually
105 cover many different targets for different architectures, machines, and
106 distributions, as well as different configurations, such as different init
107 systems. The Autobuilder tests literally hundreds of configurations and
108 targets. <itemizedlist>
109 <listitem>
110 <para>
111 <emphasis>Sanity Checks During the Build Process:</emphasis>
112 Tests initiated through the <ulink
113 url="&YOCTO_DOCS_REF_URL;#ref-classes-insane"
114 ><filename>insane</filename></ulink> class. These checks
115 ensure the output of the builds are correct. For example, does
116 the ELF architecture in the generated binaries match the target
117 system? ARM binaries would not work in a MIPS system! </para>
118 </listitem>
119 </itemizedlist></para>
120 </listitem>
121 <listitem>
122 <para>
123 <emphasis>Build Performance Testing:</emphasis> Tests whether or not
124 commonly used steps during builds work efficiently and avoid regressions.
125 Tests to time commonly used usage scenarios are run through
126 <filename>oe-build-perf-test</filename>. These tests are run on isolated
127 machines so that the time measurements of the tests are accurate and no
128 other processes interfere with the timing results. The project currently
129 tests performance on two different distributions, Fedora and Ubuntu, to
130 ensure we have no single point of failure and can ensure the different
131 distros work effectively. </para>
132 </listitem>
133 <listitem>
134 <para>
135 <emphasis>eSDK Testing:</emphasis> Image tests initiated through the
136 following command:
137 <literallayout class="monospaced">
138 $ bitbake <replaceable>image</replaceable> -c testsdkext
139 </literallayout>
140 The tests utilize the <filename>testsdkext</filename> class and the
141 <filename>do_testsdkext</filename> task. </para>
142 </listitem>
143 <listitem>
144 <para>
145 <emphasis>Feature Testing:</emphasis> Various scenario-based tests are run
146 through the <ulink url="&YOCTO_DOCS_REF_URL;#testing-and-quality-assurance"
147 >OpenEmbedded Self-Test</ulink> (oe-selftest). We test oe-selftest on
148 each of the main distrubutions we support. </para>
149 </listitem>
150 <listitem>
151 <para>
152 <emphasis>Image Testing:</emphasis> Image tests initiated through the
153 following command:
154 <literallayout class="monospaced">
155 $ bitbake <replaceable>image</replaceable> -c testimage
156 </literallayout>
157 The tests utilize the <ulink
158 url="&YOCTO_DOCS_REF_URL;#ref-classes-testimage*"
159 ><filename>testimage*</filename></ulink> classes and the <ulink
160 url="&YOCTO_DOCS_REF_URL;#ref-tasks-testimage"
161 ><filename>do_testimage</filename></ulink> task. </para>
162 </listitem>
163 <listitem>
164 <para>
165 <emphasis>Layer Testing:</emphasis> The Autobuilder has the possibility to
166 test whether specific layers work with the test of the system. The layers
167 tested may be selected by members of the project. Some key community layers
168 are also tested periodically.</para>
169 </listitem>
170 <listitem>
171 <para>
172 <emphasis>Package Testing:</emphasis> A Package Test (ptest) runs tests
173 against packages built by the OpenEmbedded build system on the target
174 machine. See the "<ulink
175 url="&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest">Testing Packages
176 With ptest</ulink>" section in the Yocto Project Development Tasks
177 Manual and the "<ulink url="&YOCTO_WIKI_URL;/wiki/Ptest">Ptest</ulink>" Wiki
178 page for more information on Ptest. </para>
179 </listitem>
180 <listitem>
181 <para>
182 <emphasis>SDK Testing:</emphasis> Image tests initiated through the
183 following command:
184 <literallayout class="monospaced">
185 $ bitbake <replaceable>image</replaceable> -c testsdk
186 </literallayout>
187 The tests utilize the <ulink url="&YOCTO_DOCS_REF_URL;#ref-classes-testsdk"
188 ><filename>testsdk</filename></ulink> class and the
189 <filename>do_testsdk</filename> task. </para>
190 </listitem>
191 <listitem>
192 <para>
193 <emphasis>Unit Testing:</emphasis> Unit tests on various components of the
194 system run through <filename>oe-selftest</filename> and <ulink
195 url="&YOCTO_DOCS_REF_URL;#testing-and-quality-assurance"
196 ><filename>bitbake-selftest</filename></ulink>. </para>
197 </listitem>
198 <listitem>
199 <para>
200 <emphasis>Automatic Upgrade Helper:</emphasis> This target tests whether new
201 versions of software are available and whether we can automatically upgrade
202 to those new versions. If so, this target emails the maintainers with a
203 patch to let them know this is possible.</para>
204 </listitem>
205 </itemizedlist>
206 </para>
207 </section>
208
209 <section id='test-test-mapping'>
210 <title>How Tests Map to Areas of Code</title>
211
212 <para>
213 Tests map into the codebase as follows:
214 <itemizedlist>
215 <listitem><para>
216 <emphasis>bitbake-selftest</emphasis>: <itemizedlist>
217 <listitem>
218 <para>These tests are self-contained and test BitBake as well as its
219 APIs, which include the fetchers. The tests are located in
220 <filename>bitbake/lib/*/tests</filename>. </para>
221 </listitem>
222 <listitem>
223 <para>From within the BitBake repository, run the following:
224 <literallayout class="monospaced">
225 $ bitbake-selftest
226 </literallayout>
227 </para>
228 </listitem>
229 <listitem>
230 <para>To skip tests that access the Internet, use the
231 <filename>BB_SKIP_NETTEST</filename> variable when running
232 "bitbake-selftest" as follows:
233 <literallayout class="monospaced">
234 $ BB_SKIP_NETTEST=yes bitbake-selftest
235 </literallayout>The
236 default output is quiet and just prints a summary of what was
237 run. To see more information, there is a verbose
238 option:<literallayout>
239 $ bitbake-selftest -v
240 </literallayout></para>
241 <para>Use this option when you wish to skip tests that access the
242 network, which are mostly necessary to test the fetcher modules.
243 To specify individual test modules to run, append the test
244 module name to the "bitbake-selftest" command. For example, to
245 specify the tests for the bb.data.module, run:
246 <literallayout class="monospaced">
247 $ bitbake-selftest bb.test.data.module
248 </literallayout>You
249 can also specify individual tests by defining the full name and
250 module plus the class path of the test, for example:
251 <literallayout>
252 $ bitbake-selftest bb.tests.data.TestOverrides.test_one_override
253 </literallayout></para>
254 </listitem>
255 <listitem>
256 <para>The tests are based on <ulink
257 url="https://docs.python.org/3/library/unittest.html">Python
258 unittest</ulink>. </para>
259 </listitem>
260 </itemizedlist>
261 </para></listitem>
262 <listitem><para>
263 <emphasis>oe-selftest</emphasis>: <itemizedlist>
264 <listitem>
265 <para>These tests use OE to test the workflows, which include
266 testing specific features, behaviors of tasks, and API unit
267 tests. </para>
268 </listitem>
269 <listitem>
270 <para>The tests can take advantage of parallelism through the "-j"
271 option, which can specify a number of threads to spread the
272 tests across. Note that all tests from a given class of tests
273 will run in the same thread. To parallelize large numbers of
274 tests you can split the class into multiple units.</para>
275 </listitem>
276 <listitem>
277 <para>The tests are based on Python unittest. </para>
278 </listitem>
279 <listitem>
280 <para>The code for the tests resides in
281 <filename>meta/lib/oeqa/selftest/cases/</filename>. </para>
282 </listitem>
283 <listitem>
284 <para>To run all the tests, enter the following command:
285 <literallayout class="monospaced">
286 $ oe-selftest -a
287 </literallayout>
288 </para>
289 </listitem>
290 <listitem>
291 <para>To run a specific test, use the following command form where
292 <replaceable>testname</replaceable> is the name of the
293 specific test:
294 <literallayout class="monospaced">
295 $ oe-selftest -r <replaceable>testname</replaceable>
296 </literallayout>
297 For example, the following command would run the tinfoil getVar
298 API
299 test:<literallayout>
300 $ oe-selftest -r tinfoil.TinfoilTests.test_getvar
301 </literallayout>It
302 is also possible to run a set of tests. For example the
303 following command will run all of the tinfoil
304 tests:<literallayout>
305 $ oe-selftest -r tinfoil
306 </literallayout></para>
307 </listitem>
308 </itemizedlist>
309 </para></listitem>
310 <listitem><para>
311 <emphasis>testimage:</emphasis>
312 <itemizedlist>
313 <listitem><para>
314 These tests build an image, boot it, and run tests
315 against the image's content.
316 </para></listitem>
317 <listitem><para> The code for these tests resides in <filename>meta/lib/oeqa/runtime/cases/</filename>. </para></listitem>
318 <listitem><para>
319 You need to set the
320 <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_CLASSES'><filename>IMAGE_CLASSES</filename></ulink>
321 variable as follows:
322 <literallayout class='monospaced'>
323 IMAGE_CLASSES += "testimage"
324 </literallayout>
325 </para></listitem>
326 <listitem><para>
327 Run the tests using the following command form:
328 <literallayout class='monospaced'>
329 $ bitbake <replaceable>image</replaceable> -c testimage
330 </literallayout>
331 </para></listitem>
332 </itemizedlist>
333 </para></listitem>
334 <listitem><para>
335 <emphasis>testsdk:</emphasis>
336 <itemizedlist>
337 <listitem><para>These tests build an SDK, install it, and then run tests against that SDK. </para></listitem>
338 <listitem><para>The code for these tests resides in <filename>meta/lib/oeqa/sdk/cases/</filename>. </para></listitem>
339 <listitem><para>Run the test using the following command form:
340 <literallayout class="monospaced">
341 $ bitbake <replaceable>image</replaceable> -c testsdk
342 </literallayout>
343 </para></listitem>
344 </itemizedlist>
345 </para></listitem>
346 <listitem><para>
347 <emphasis>testsdk_ext:</emphasis>
348 <itemizedlist>
349 <listitem><para>These tests build an extended SDK (eSDK), install that eSDK, and run tests against the eSDK. </para></listitem>
350 <listitem><para>The code for these tests resides in <filename>meta/lib/oeqa/esdk</filename>. </para></listitem>
351 <listitem><para>To run the tests, use the following command form:
352 <literallayout class="monospaced">
353 $ bitbake <replaceable>image</replaceable> -c testsdkext
354 </literallayout>
355 </para></listitem>
356 </itemizedlist>
357 </para></listitem>
358
359
360 <listitem><para>
361 <emphasis>oe-build-perf-test:</emphasis>
362 <itemizedlist>
363 <listitem><para>These tests run through commonly used usage scenarios and measure the performance times. </para></listitem>
364 <listitem><para>The code for these tests resides in <filename>meta/lib/oeqa/buildperf</filename>. </para></listitem>
365 <listitem><para>To run the tests, use the following command form:
366 <literallayout class="monospaced">
367 $ oe-build-perf-test <replaceable>options</replaceable>
368 </literallayout>The
369 command takes a number of options, such as where to place the
370 test results. The Autobuilder Helper Scripts include the
371 <filename>build-perf-test-wrapper</filename> script with
372 examples of how to use the oe-build-perf-test from the command
373 line.</para>
374 <para>Use the <filename>oe-git-archive</filename> command to store
375 test results into a Git repository. </para>
376 <para>Use the <filename>oe-build-perf-report</filename> command to
377 generate text reports and HTML reports with graphs of the
378 performance data. For examples, see <link linkend=""
379 >http://downloads.yoctoproject.org/releases/yocto/yocto-2.7/testresults/buildperf-centos7/perf-centos7.yoctoproject.org_warrior_20190414204758_0e39202.html</link>
380 and <link linkend=""
381 >http://downloads.yoctoproject.org/releases/yocto/yocto-2.7/testresults/buildperf-centos7/perf-centos7.yoctoproject.org_warrior_20190414204758_0e39202.txt</link>.</para></listitem>
382 <listitem>
383 <para>The tests are contained in
384 <filename>lib/oeqa/buildperf/test_basic.py</filename>.</para>
385 </listitem>
386 </itemizedlist>
387 </para></listitem>
388
389
390
391
392 </itemizedlist>
393 </para>
394 </section>
395
396 <section id='test-examples'>
397 <title>Test Examples</title>
398
399 <para>This section provides example tests for each of the tests listed in the <link
400 linkend="test-test-mapping">How Tests Map to Areas of Code</link> section. </para>
401 <para>For oeqa tests, testcases for each area reside in the main test directory at
402 <filename>meta/lib/oeqa/selftest/cases</filename> directory.</para>
403 <para>For oe-selftest. bitbake testcases reside in the <filename>lib/bb/tests/</filename>
404 directory. </para>
405
406 <section id='bitbake-selftest-example'>
407 <title><filename>bitbake-selftest</filename></title>
408
409 <para>A simple test example from <filename>lib/bb/tests/data.py</filename> is:
410 <literallayout>
411 class DataExpansions(unittest.TestCase):
412 def setUp(self):
413 self.d = bb.data.init()
414 self.d["foo"] = "value_of_foo"
415 self.d["bar"] = "value_of_bar"
416 self.d["value_of_foo"] = "value_of_'value_of_foo'"
417
418 def test_one_var(self):
419 val = self.d.expand("${foo}")
420 self.assertEqual(str(val), "value_of_foo")
421 </literallayout>
422 </para>
423 <para>In this example, a <ulink url=""><filename>DataExpansions</filename></ulink> class
424 of tests is created, derived from standard python unittest. The class has a common
425 <filename>setUp</filename> function which is shared by all the tests in the
426 class. A simple test is then added to test that when a variable is expanded, the
427 correct value is found.</para>
428 <para>Bitbake selftests are straightforward python unittest. Refer to the Python
429 unittest documentation for additional information on writing these tests at: <link
430 linkend="">https://docs.python.org/3/library/unittest.html</link>.</para>
431 </section>
432
433 <section id='oe-selftest-example'>
434 <title><filename>oe-selftest</filename></title>
435
436 <para>These tests are more complex due to the setup required behind the scenes for full
437 builds. Rather than directly using Python's unittest, the code wraps most of the
438 standard objects. The tests can be simple, such as testing a command from within the
439 OE build environment using the following
440 example:<literallayout>
441 class BitbakeLayers(OESelftestTestCase):
442 def test_bitbakelayers_showcrossdepends(self):
443 result = runCmd('bitbake-layers show-cross-depends')
444 self.assertTrue('aspell' in result.output, msg = "No dependencies
445 were shown. bitbake-layers show-cross-depends output:
446 %s"% result.output)
447 </literallayout></para>
448 <para>This example, taken from
449 <filename>meta/lib/oeqa/selftest/cases/bblayers.py</filename>, creates a
450 testcase from the <ulink url=""><filename>OESelftestTestCase</filename></ulink>
451 class, derived from <filename>unittest.TestCase</filename>, which runs the
452 <filename>bitbake-layers</filename> command and checks the output to ensure it
453 contains something we know should be here.</para>
454 <para>The <filename>oeqa.utils.commands</filename> module contains Helpers which can
455 assist with common tasks, including:<itemizedlist>
456 <listitem>
457 <para><emphasis>Obtaining the value of a bitbake variable:</emphasis> Use
458 <filename>oeqa.utils.commands.get_bb_var()</filename> or use
459 <filename>oeqa.utils.commands.get_bb_vars()</filename> for more than
460 one variable</para>
461 </listitem>
462 <listitem>
463 <para><emphasis>Running a bitbake invocation for a build:</emphasis> Use
464 <filename>oeqa.utils.commands.bitbake()</filename></para>
465 </listitem>
466 <listitem>
467 <para><emphasis>Running a command:</emphasis> Use
468 <filename>oeqa.utils.commandsrunCmd()</filename></para>
469 </listitem>
470 </itemizedlist></para>
471 <para>There is also a <filename>oeqa.utils.commands.runqemu()</filename> function for
472 launching the <filename>runqemu</filename> command for testing things within a
473 running, virtualized image.</para>
474 <para>You can run these tests in parallel. Parallelism works per test class, so tests
475 within a given test class should always run in the same build, while tests in
476 different classes or modules may be split into different builds. There is no data
477 store available for these tests since the tests launch the
478 <filename>bitbake</filename> command and exist outside of its context. As a
479 result, common bitbake library functions (bb.*) are also unavailable.</para>
480 </section>
481
482 <section id='testimage-example'>
483 <title><filename>testimage</filename></title>
484
485 <para>These tests are run once an image is up and running, either on target hardware or
486 under QEMU. As a result, they are assumed to be running in a target image
487 environment, as opposed to a host build environment. A simple example from
488 <filename>meta/lib/oeqa/runtime/cases/python.py</filename> contains the
489 following:<literallayout>
490 class PythonTest(OERuntimeTestCase):
491 @OETestDepends(['ssh.SSHTest.test_ssh'])
492 @OEHasPackage(['python3-core'])
493 def test_python3(self):
494 cmd = "python3 -c \"import codecs; print(codecs.encode('Uryyb,
495 jbeyq', 'rot13'))\""
496 status, output = self.target.run(cmd)
497 msg = 'Exit status was not 0. Output: %s' % output
498 self.assertEqual(status, 0, msg=msg)
499 </literallayout></para>
500 <para>In this example, the <ulink url=""><filename>OERuntimeTestCase</filename></ulink>
501 class wraps <filename>unittest.TestCase</filename>. Within the test,
502 <filename>self.target</filename> represents the target system, where commands
503 can be run on it using the <filename>run()</filename> method. </para>
504 <para>To ensure certain test or package dependencies are met, you can use the
505 <filename>OETestDepends</filename> and <filename>OEHasPackage</filename>
506 decorators. For example, the test in this example would only make sense if
507 python3-core is installed in the image.</para>
508 </section>
509
510 <section id='testsdk_ext-example'>
511 <title><filename>testsdk_ext</filename></title>
512
513 <para>These tests are run against built extensible SDKs (eSDKs). The tests can assume
514 that the eSDK environment has already been setup. An example from
515 <filename>meta/lib/oeqa/sdk/cases/devtool.py</filename> contains the
516 following:<literallayout>
517 class DevtoolTest(OESDKExtTestCase):
518 @classmethod
519 def setUpClass(cls):
520 myapp_src = os.path.join(cls.tc.esdk_files_dir, "myapp")
521 cls.myapp_dst = os.path.join(cls.tc.sdk_dir, "myapp")
522 shutil.copytree(myapp_src, cls.myapp_dst)
523 subprocess.check_output(['git', 'init', '.'], cwd=cls.myapp_dst)
524 subprocess.check_output(['git', 'add', '.'], cwd=cls.myapp_dst)
525 subprocess.check_output(['git', 'commit', '-m', "'test commit'"], cwd=cls.myapp_dst)
526
527 @classmethod
528 def tearDownClass(cls):
529 shutil.rmtree(cls.myapp_dst)
530 def _test_devtool_build(self, directory):
531 self._run('devtool add myapp %s' % directory)
532 try:
533 self._run('devtool build myapp')
534 finally:
535 self._run('devtool reset myapp')
536 def test_devtool_build_make(self):
537 self._test_devtool_build(self.myapp_dst)
538 </literallayout>In
539 this example, the <filename>devtool</filename> command is tested to see whether a
540 sample application can be built with the <filename>devtool build</filename> command
541 within the eSDK.</para>
542 </section>
543
544 <section id='testsdk-example'>
545 <title><filename>testsdk</filename></title>
546
547 <para>These tests are run against built SDKs. The tests can assume that an SDK has
548 already been extracted and its environment file has been sourced. A simple example
549 from <filename>meta/lib/oeqa/sdk/cases/python2.py</filename> contains the
550 following:<literallayout>
551 class Python3Test(OESDKTestCase):
552 def setUp(self):
553 if not (self.tc.hasHostPackage("nativesdk-python3-core") or
554 self.tc.hasHostPackage("python3-core-native")):
555 raise unittest.SkipTest("No python3 package in the SDK")
556
557 def test_python3(self):
558 cmd = "python3 -c \"import codecs; print(codecs.encode('Uryyb, jbeyq', 'rot13'))\""
559 output = self._run(cmd)
560 self.assertEqual(output, "Hello, world\n")
561 </literallayout>In
562 this example, if nativesdk-python3-core has been installed into the SDK, the code
563 runs the python3 interpreter with a basic command to check it is working correctly.
564 The test would only run if python3 is installed in the SDK.</para>
565 </section>
566
567 <section id='oe-build-perf-test-example'>
568 <title><filename>oe-build-perf-test</filename></title>
569
570 <para>The performance tests usually measure how long operations take and the resource
571 utilisation as that happens. An example from
572 <filename>meta/lib/oeqa/buildperf/test_basic.py</filename> contains the
573 following:<literallayout>
574 class Test3(BuildPerfTestCase):
575
576 def test3(self):
577 """Bitbake parsing (bitbake -p)"""
578 # Drop all caches and parse
579 self.rm_cache()
580 oe.path.remove(os.path.join(self.bb_vars['TMPDIR'], 'cache'), True)
581 self.measure_cmd_resources(['bitbake', '-p'], 'parse_1',
582 'bitbake -p (no caches)')
583 # Drop tmp/cache
584 oe.path.remove(os.path.join(self.bb_vars['TMPDIR'], 'cache'), True)
585 self.measure_cmd_resources(['bitbake', '-p'], 'parse_2',
586 'bitbake -p (no tmp/cache)')
587 # Parse with fully cached data
588 self.measure_cmd_resources(['bitbake', '-p'], 'parse_3',
589 'bitbake -p (cached)')
590 </literallayout>This
591 example shows how three specific parsing timings are measured, with and without
592 various caches, to show how BitBake’s parsing performance trends over time.</para>
593 </section>
594 </section>
595 <section id='test-writing-considerations'>
596 <title>Considerations When Writing Tests</title>
597 <para>When writing good tests, there are several things to keep in mind. Since things
598 running on the Autobuilder are accessed concurrently by multiple workers, consider the
599 following:</para>
600 <formalpara>
601 <title>Running "cleanall" is not permitted</title>
602 <para>This can delete files from DL_DIR which would potentially break other builds
603 running in parallel. If this is required, DL_DIR must be set to an isolated
604 directory.</para>
605 </formalpara>
606 <formalpara>
607 <title>Running "cleansstate" is not permitted</title>
608 <para>This can delete files from SSTATE_DIR which would potentially break other builds
609 running in parallel. If this is required, SSTATE_DIR must be set to an isolated
610 directory. Alternatively, you can use the "-f" option with the
611 <filename>bitbake</filename> command to "taint" tasks by changing the sstate
612 checksums to ensure sstate cache items will not be reused.</para>
613 </formalpara>
614 <formalpara>
615 <title>Tests should not change the metadata</title>
616 <para>This is particularly true for oe-selftests since these can run in parallel and
617 changing metadata leads to changing checksums, which confuses BitBake while running
618 in parallel. If this is necessary, copy layers to a temporary location and modify
619 them. Some tests need to change metadata, such as the devtool tests. To prevent the
620 metadate from changes, set up temporary copies of that data first.</para>
621 </formalpara>
622 </section>
623
624
625
626
627
628
629
630
631</chapter>
632<!--
633vim: expandtab tw=80 ts=4
634-->
diff --git a/documentation/test-manual/test-manual-style.css b/documentation/test-manual/test-manual-style.css
new file mode 100644
index 0000000000..15ff718b16
--- /dev/null
+++ b/documentation/test-manual/test-manual-style.css
@@ -0,0 +1,989 @@
1/*
2 Generic XHTML / DocBook XHTML CSS Stylesheet.
3
4 Browser wrangling and typographic design by
5 Oyvind Kolas / pippin@gimp.org
6
7 Customised for Poky by
8 Matthew Allum / mallum@o-hand.com
9
10 Thanks to:
11 Liam R. E. Quin
12 William Skaggs
13 Jakub Steiner
14
15 Structure
16 ---------
17
18 The stylesheet is divided into the following sections:
19
20 Positioning
21 Margins, paddings, width, font-size, clearing.
22 Decorations
23 Borders, style
24 Colors
25 Colors
26 Graphics
27 Graphical backgrounds
28 Nasty IE tweaks
29 Workarounds needed to make it work in internet explorer,
30 currently makes the stylesheet non validating, but up until
31 this point it is validating.
32 Mozilla extensions
33 Transparency for footer
34 Rounded corners on boxes
35
36*/
37
38
39 /*************** /
40 / Positioning /
41/ ***************/
42
43body {
44 font-family: Verdana, Sans, sans-serif;
45
46 min-width: 640px;
47 width: 80%;
48 margin: 0em auto;
49 padding: 2em 5em 5em 5em;
50 color: #333;
51}
52
53h1,h2,h3,h4,h5,h6,h7 {
54 font-family: Arial, Sans;
55 color: #00557D;
56 clear: both;
57}
58
59h1 {
60 font-size: 2em;
61 text-align: left;
62 padding: 0em 0em 0em 0em;
63 margin: 2em 0em 0em 0em;
64}
65
66h2.subtitle {
67 margin: 0.10em 0em 3.0em 0em;
68 padding: 0em 0em 0em 0em;
69 font-size: 1.8em;
70 padding-left: 20%;
71 font-weight: normal;
72 font-style: italic;
73}
74
75h2 {
76 margin: 2em 0em 0.66em 0em;
77 padding: 0.5em 0em 0em 0em;
78 font-size: 1.5em;
79 font-weight: bold;
80}
81
82h3.subtitle {
83 margin: 0em 0em 1em 0em;
84 padding: 0em 0em 0em 0em;
85 font-size: 142.14%;
86 text-align: right;
87}
88
89h3 {
90 margin: 1em 0em 0.5em 0em;
91 padding: 1em 0em 0em 0em;
92 font-size: 140%;
93 font-weight: bold;
94}
95
96h4 {
97 margin: 1em 0em 0.5em 0em;
98 padding: 1em 0em 0em 0em;
99 font-size: 120%;
100 font-weight: bold;
101}
102
103h5 {
104 margin: 1em 0em 0.5em 0em;
105 padding: 1em 0em 0em 0em;
106 font-size: 110%;
107 font-weight: bold;
108}
109
110h6 {
111 margin: 1em 0em 0em 0em;
112 padding: 1em 0em 0em 0em;
113 font-size: 110%;
114 font-weight: bold;
115}
116
117.authorgroup {
118 background-color: transparent;
119 background-repeat: no-repeat;
120 padding-top: 256px;
121 background-image: url("figures/test-manual-title.png");
122 background-position: left top;
123 margin-top: -256px;
124 padding-right: 50px;
125 margin-left: 0px;
126 text-align: right;
127 width: 740px;
128}
129
130h3.author {
131 margin: 0em 0me 0em 0em;
132 padding: 0em 0em 0em 0em;
133 font-weight: normal;
134 font-size: 100%;
135 color: #333;
136 clear: both;
137}
138
139.author tt.email {
140 font-size: 66%;
141}
142
143.titlepage hr {
144 width: 0em;
145 clear: both;
146}
147
148.revhistory {
149 padding-top: 2em;
150 clear: both;
151}
152
153.toc,
154.list-of-tables,
155.list-of-examples,
156.list-of-figures {
157 padding: 1.33em 0em 2.5em 0em;
158 color: #00557D;
159}
160
161.toc p,
162.list-of-tables p,
163.list-of-figures p,
164.list-of-examples p {
165 padding: 0em 0em 0em 0em;
166 padding: 0em 0em 0.3em;
167 margin: 1.5em 0em 0em 0em;
168}
169
170.toc p b,
171.list-of-tables p b,
172.list-of-figures p b,
173.list-of-examples p b{
174 font-size: 100.0%;
175 font-weight: bold;
176}
177
178.toc dl,
179.list-of-tables dl,
180.list-of-figures dl,
181.list-of-examples dl {
182 margin: 0em 0em 0.5em 0em;
183 padding: 0em 0em 0em 0em;
184}
185
186.toc dt {
187 margin: 0em 0em 0em 0em;
188 padding: 0em 0em 0em 0em;
189}
190
191.toc dd {
192 margin: 0em 0em 0em 2.6em;
193 padding: 0em 0em 0em 0em;
194}
195
196div.glossary dl,
197div.variablelist dl {
198}
199
200.glossary dl dt,
201.variablelist dl dt,
202.variablelist dl dt span.term {
203 font-weight: normal;
204 width: 20em;
205 text-align: right;
206}
207
208.variablelist dl dt {
209 margin-top: 0.5em;
210}
211
212.glossary dl dd,
213.variablelist dl dd {
214 margin-top: 0em;
215 margin-left: 25.5em;
216}
217
218.glossary dd p,
219.variablelist dd p {
220 margin-top: 0em;
221 margin-bottom: 1em;
222}
223
224
225div.calloutlist table td {
226 padding: 0em 0em 0em 0em;
227 margin: 0em 0em 0em 0em;
228}
229
230div.calloutlist table td p {
231 margin-top: 0em;
232 margin-bottom: 1em;
233}
234
235div p.copyright {
236 text-align: left;
237}
238
239div.legalnotice p.legalnotice-title {
240 margin-bottom: 0em;
241}
242
243p {
244 line-height: 1.5em;
245 margin-top: 0em;
246
247}
248
249dl {
250 padding-top: 0em;
251}
252
253hr {
254 border: solid 1px;
255}
256
257
258.mediaobject,
259.mediaobjectco {
260 text-align: center;
261}
262
263img {
264 border: none;
265}
266
267ul {
268 padding: 0em 0em 0em 1.5em;
269}
270
271ul li {
272 padding: 0em 0em 0em 0em;
273}
274
275ul li p {
276 text-align: left;
277}
278
279table {
280 width :100%;
281}
282
283th {
284 padding: 0.25em;
285 text-align: left;
286 font-weight: normal;
287 vertical-align: top;
288}
289
290td {
291 padding: 0.25em;
292 vertical-align: top;
293}
294
295p a[id] {
296 margin: 0px;
297 padding: 0px;
298 display: inline;
299 background-image: none;
300}
301
302a {
303 text-decoration: underline;
304 color: #444;
305}
306
307pre {
308 overflow: auto;
309}
310
311a:hover {
312 text-decoration: underline;
313 /*font-weight: bold;*/
314}
315
316/* This style defines how the permalink character
317 appears by itself and when hovered over with
318 the mouse. */
319
320[alt='Permalink'] { color: #eee; }
321[alt='Permalink']:hover { color: black; }
322
323
324div.informalfigure,
325div.informalexample,
326div.informaltable,
327div.figure,
328div.table,
329div.example {
330 margin: 1em 0em;
331 padding: 1em;
332 page-break-inside: avoid;
333}
334
335
336div.informalfigure p.title b,
337div.informalexample p.title b,
338div.informaltable p.title b,
339div.figure p.title b,
340div.example p.title b,
341div.table p.title b{
342 padding-top: 0em;
343 margin-top: 0em;
344 font-size: 100%;
345 font-weight: normal;
346}
347
348.mediaobject .caption,
349.mediaobject .caption p {
350 text-align: center;
351 font-size: 80%;
352 padding-top: 0.5em;
353 padding-bottom: 0.5em;
354}
355
356.epigraph {
357 padding-left: 55%;
358 margin-bottom: 1em;
359}
360
361.epigraph p {
362 text-align: left;
363}
364
365.epigraph .quote {
366 font-style: italic;
367}
368.epigraph .attribution {
369 font-style: normal;
370 text-align: right;
371}
372
373span.application {
374 font-style: italic;
375}
376
377.programlisting {
378 font-family: monospace;
379 font-size: 80%;
380 white-space: pre;
381 margin: 1.33em 0em;
382 padding: 1.33em;
383}
384
385.tip,
386.warning,
387.caution,
388.note {
389 margin-top: 1em;
390 margin-bottom: 1em;
391
392}
393
394/* force full width of table within div */
395.tip table,
396.warning table,
397.caution table,
398.note table {
399 border: none;
400 width: 100%;
401}
402
403
404.tip table th,
405.warning table th,
406.caution table th,
407.note table th {
408 padding: 0.8em 0.0em 0.0em 0.0em;
409 margin : 0em 0em 0em 0em;
410}
411
412.tip p,
413.warning p,
414.caution p,
415.note p {
416 margin-top: 0.5em;
417 margin-bottom: 0.5em;
418 padding-right: 1em;
419 text-align: left;
420}
421
422.acronym {
423 text-transform: uppercase;
424}
425
426b.keycap,
427.keycap {
428 padding: 0.09em 0.3em;
429 margin: 0em;
430}
431
432.itemizedlist li {
433 clear: none;
434}
435
436.filename {
437 font-size: medium;
438 font-family: Courier, monospace;
439}
440
441
442div.navheader, div.heading{
443 position: absolute;
444 left: 0em;
445 top: 0em;
446 width: 100%;
447 background-color: #cdf;
448 width: 100%;
449}
450
451div.navfooter, div.footing{
452 position: fixed;
453 left: 0em;
454 bottom: 0em;
455 background-color: #eee;
456 width: 100%;
457}
458
459
460div.navheader td,
461div.navfooter td {
462 font-size: 66%;
463}
464
465div.navheader table th {
466 /*font-family: Georgia, Times, serif;*/
467 /*font-size: x-large;*/
468 font-size: 80%;
469}
470
471div.navheader table {
472 border-left: 0em;
473 border-right: 0em;
474 border-top: 0em;
475 width: 100%;
476}
477
478div.navfooter table {
479 border-left: 0em;
480 border-right: 0em;
481 border-bottom: 0em;
482 width: 100%;
483}
484
485div.navheader table td a,
486div.navfooter table td a {
487 color: #777;
488 text-decoration: none;
489}
490
491/* normal text in the footer */
492div.navfooter table td {
493 color: black;
494}
495
496div.navheader table td a:visited,
497div.navfooter table td a:visited {
498 color: #444;
499}
500
501
502/* links in header and footer */
503div.navheader table td a:hover,
504div.navfooter table td a:hover {
505 text-decoration: underline;
506 background-color: transparent;
507 color: #33a;
508}
509
510div.navheader hr,
511div.navfooter hr {
512 display: none;
513}
514
515
516.qandaset tr.question td p {
517 margin: 0em 0em 1em 0em;
518 padding: 0em 0em 0em 0em;
519}
520
521.qandaset tr.answer td p {
522 margin: 0em 0em 1em 0em;
523 padding: 0em 0em 0em 0em;
524}
525.answer td {
526 padding-bottom: 1.5em;
527}
528
529.emphasis {
530 font-weight: bold;
531}
532
533
534 /************* /
535 / decorations /
536/ *************/
537
538.titlepage {
539}
540
541.part .title {
542}
543
544.subtitle {
545 border: none;
546}
547
548/*
549h1 {
550 border: none;
551}
552
553h2 {
554 border-top: solid 0.2em;
555 border-bottom: solid 0.06em;
556}
557
558h3 {
559 border-top: 0em;
560 border-bottom: solid 0.06em;
561}
562
563h4 {
564 border: 0em;
565 border-bottom: solid 0.06em;
566}
567
568h5 {
569 border: 0em;
570}
571*/
572
573.programlisting {
574 border: solid 1px;
575}
576
577div.figure,
578div.table,
579div.informalfigure,
580div.informaltable,
581div.informalexample,
582div.example {
583 border: 1px solid;
584}
585
586
587
588.tip,
589.warning,
590.caution,
591.note {
592 border: 1px solid;
593}
594
595.tip table th,
596.warning table th,
597.caution table th,
598.note table th {
599 border-bottom: 1px solid;
600}
601
602.question td {
603 border-top: 1px solid black;
604}
605
606.answer {
607}
608
609
610b.keycap,
611.keycap {
612 border: 1px solid;
613}
614
615
616div.navheader, div.heading{
617 border-bottom: 1px solid;
618}
619
620
621div.navfooter, div.footing{
622 border-top: 1px solid;
623}
624
625 /********* /
626 / colors /
627/ *********/
628
629body {
630 color: #333;
631 background: white;
632}
633
634a {
635 background: transparent;
636}
637
638a:hover {
639 background-color: #dedede;
640}
641
642
643h1,
644h2,
645h3,
646h4,
647h5,
648h6,
649h7,
650h8 {
651 background-color: transparent;
652}
653
654hr {
655 border-color: #aaa;
656}
657
658
659.tip, .warning, .caution, .note {
660 border-color: #fff;
661}
662
663
664.tip table th,
665.warning table th,
666.caution table th,
667.note table th {
668 border-bottom-color: #fff;
669}
670
671
672.warning {
673 background-color: #f0f0f2;
674}
675
676.caution {
677 background-color: #f0f0f2;
678}
679
680.tip {
681 background-color: #f0f0f2;
682}
683
684.note {
685 background-color: #f0f0f2;
686}
687
688.glossary dl dt,
689.variablelist dl dt,
690.variablelist dl dt span.term {
691 color: #044;
692}
693
694div.figure,
695div.table,
696div.example,
697div.informalfigure,
698div.informaltable,
699div.informalexample {
700 border-color: #aaa;
701}
702
703pre.programlisting {
704 color: black;
705 background-color: #fff;
706 border-color: #aaa;
707 border-width: 2px;
708}
709
710.guimenu,
711.guilabel,
712.guimenuitem {
713 background-color: #eee;
714}
715
716
717b.keycap,
718.keycap {
719 background-color: #eee;
720 border-color: #999;
721}
722
723
724div.navheader {
725 border-color: black;
726}
727
728
729div.navfooter {
730 border-color: black;
731}
732
733.writernotes {
734 color: red;
735}
736
737
738 /*********** /
739 / graphics /
740/ ***********/
741
742/*
743body {
744 background-image: url("images/body_bg.jpg");
745 background-attachment: fixed;
746}
747
748.navheader,
749.note,
750.tip {
751 background-image: url("images/note_bg.jpg");
752 background-attachment: fixed;
753}
754
755.warning,
756.caution {
757 background-image: url("images/warning_bg.jpg");
758 background-attachment: fixed;
759}
760
761.figure,
762.informalfigure,
763.example,
764.informalexample,
765.table,
766.informaltable {
767 background-image: url("images/figure_bg.jpg");
768 background-attachment: fixed;
769}
770
771*/
772h1,
773h2,
774h3,
775h4,
776h5,
777h6,
778h7{
779}
780
781/*
782Example of how to stick an image as part of the title.
783
784div.article .titlepage .title
785{
786 background-image: url("figures/white-on-black.png");
787 background-position: center;
788 background-repeat: repeat-x;
789}
790*/
791
792div.preface .titlepage .title,
793div.colophon .title,
794div.chapter .titlepage .title,
795div.article .titlepage .title
796{
797}
798
799div.section div.section .titlepage .title,
800div.sect2 .titlepage .title {
801 background: none;
802}
803
804
805h1.title {
806 background-color: transparent;
807 background-image: url("figures/test-title.png");
808 background-repeat: no-repeat;
809 height: 256px;
810 text-indent: -9000px;
811 overflow:hidden;
812}
813
814h2.subtitle {
815 background-color: transparent;
816 text-indent: -9000px;
817 overflow:hidden;
818 width: 0px;
819 display: none;
820}
821
822 /*************************************** /
823 / pippin.gimp.org specific alterations /
824/ ***************************************/
825
826/*
827div.heading, div.navheader {
828 color: #777;
829 font-size: 80%;
830 padding: 0;
831 margin: 0;
832 text-align: left;
833 position: absolute;
834 top: 0px;
835 left: 0px;
836 width: 100%;
837 height: 50px;
838 background: url('/gfx/heading_bg.png') transparent;
839 background-repeat: repeat-x;
840 background-attachment: fixed;
841 border: none;
842}
843
844div.heading a {
845 color: #444;
846}
847
848div.footing, div.navfooter {
849 border: none;
850 color: #ddd;
851 font-size: 80%;
852 text-align:right;
853
854 width: 100%;
855 padding-top: 10px;
856 position: absolute;
857 bottom: 0px;
858 left: 0px;
859
860 background: url('/gfx/footing_bg.png') transparent;
861}
862*/
863
864
865
866 /****************** /
867 / nasty ie tweaks /
868/ ******************/
869
870/*
871div.heading, div.navheader {
872 width:expression(document.body.clientWidth + "px");
873}
874
875div.footing, div.navfooter {
876 width:expression(document.body.clientWidth + "px");
877 margin-left:expression("-5em");
878}
879body {
880 padding:expression("4em 5em 0em 5em");
881}
882*/
883
884 /**************************************** /
885 / mozilla vendor specific css extensions /
886/ ****************************************/
887/*
888div.navfooter, div.footing{
889 -moz-opacity: 0.8em;
890}
891
892div.figure,
893div.table,
894div.informalfigure,
895div.informaltable,
896div.informalexample,
897div.example,
898.tip,
899.warning,
900.caution,
901.note {
902 -moz-border-radius: 0.5em;
903}
904
905b.keycap,
906.keycap {
907 -moz-border-radius: 0.3em;
908}
909*/
910
911table tr td table tr td {
912 display: none;
913}
914
915
916hr {
917 display: none;
918}
919
920table {
921 border: 0em;
922}
923
924 .photo {
925 float: right;
926 margin-left: 1.5em;
927 margin-bottom: 1.5em;
928 margin-top: 0em;
929 max-width: 17em;
930 border: 1px solid gray;
931 padding: 3px;
932 background: white;
933}
934 .seperator {
935 padding-top: 2em;
936 clear: both;
937 }
938
939 #validators {
940 margin-top: 5em;
941 text-align: right;
942 color: #777;
943 }
944 @media print {
945 body {
946 font-size: 8pt;
947 }
948 .noprint {
949 display: none;
950 }
951 }
952
953
954.tip,
955.note {
956 background: #f0f0f2;
957 color: #333;
958 padding: 20px;
959 margin: 20px;
960}
961
962.tip h3,
963.note h3 {
964 padding: 0em;
965 margin: 0em;
966 font-size: 2em;
967 font-weight: bold;
968 color: #333;
969}
970
971.tip a,
972.note a {
973 color: #333;
974 text-decoration: underline;
975}
976
977.footnote {
978 font-size: small;
979 color: #333;
980}
981
982/* Changes the announcement text */
983.tip h3,
984.warning h3,
985.caution h3,
986.note h3 {
987 font-size:large;
988 color: #00557D;
989}
diff --git a/documentation/test-manual/test-manual-test-process.xml b/documentation/test-manual/test-manual-test-process.xml
new file mode 100644
index 0000000000..0b5036cd2c
--- /dev/null
+++ b/documentation/test-manual/test-manual-test-process.xml
@@ -0,0 +1,109 @@
1<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
2"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
3[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
4
5<chapter id='test-manual-test-process'>
6
7<title>Project Testing and Release Process</title>
8 <section id='test-daily-devel'>
9 <title>Day to Day Development</title>
10
11 <para>This section details how the project tests changes, through automation on the
12 Autobuilder or with the assistance of QA teams, through to making releases.</para>
13
14 <para>The project aims to test changes against our test matrix before those changes are
15 merged into the master branch. As such, changes are queued up in batches either in the
16 <filename>master-next</filename> branch in the main trees, or in user trees such as
17 <filename>ross/mut</filename> in <filename>poky-contrib</filename> (Ross Burton
18 helps review and test patches and this is his testing tree).</para>
19 <para>We have two broad categories of test builds, including "full" and "quick". On the
20 Autobuilder, these can be seen as "a-quick" and "a-full", simply for ease of sorting in
21 the UI. Use our Autobuilder console view to see where me manage most test-related items,
22 available at: <link linkend=""
23 >https://autobuilder.yoctoproject.org/typhoon/#/console</link>.</para>
24 <para>Builds are triggered manually when the test branches are ready. The builds are
25 monitored by the SWAT team. For additional information, see <link linkend=""
26 >https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team</link>. If
27 successful, the changes would usually be merged to the <filename>master</filename>
28 branch. If not successful, someone would respond to the changes on the mailing list
29 explaining that there was a failure in testing. The choice of quick or full would depend
30 on the type of changes and the speed with which the result was required.</para>
31 <para>The Autobuilder does build the <filename>master</filename> branch once daily for
32 several reasons, in particular, to ensure the current <filename>master</filename> branch
33 does build, but also to keep <filename>yocto-testresults</filename> (<link linkend=""
34 >http://git.yoctoproject.org/cgit.cgi/yocto-testresults/</link>), buildhistory
35 (<link linkend="">http://git.yoctoproject.org/cgit.cgi/poky-buildhistory/</link>),
36 and our sstate up to date. On the weekend, there is a master-next build instead to
37 ensure the test results are updated for the less frequently run targets.</para>
38 <para>Performance builds (buildperf-* targets in the console) are triggered separately every
39 six hours and automatically push their results to the buildstats repository at: <link
40 linkend="">http://git.yoctoproject.org/cgit.cgi/yocto-buildstats/</link>. </para>
41 <para>The 'quick' targets have been selected to be the ones which catch the most failures or
42 give the most valuable data. We run 'fast' ptests in this case for example but not the
43 ones which take a long time. The quick target doesn't include *-lsb builds for all
44 architectures, some world builds and doesn't trigger performance tests or ltp testing.
45 The full build includes all these things and is slower but more comprehensive.</para>
46 </section>
47
48 <section id='test-yocto-project-autobuilder-overview'>
49 <title>Release Builds</title>
50
51 <para>The project typically has two major releases a year with a six month cadence in April
52 and October. Between these there would be a number of milestone releases (usually four)
53 with the final one being stablization only along with point releases of our stable
54 branches.</para>
55 <para>The build and release process for these project releases is similar to that in <link
56 linkend="test-daily-devel">Day to Day Development</link>, in that the a-full target
57 of the Autobuilder is used but in addition the form is configured to generate and
58 publish artefacts and the milestone number, version, release candidate number and other
59 information is entered. The box to "generate an email to QA"is also checked.</para>
60 <para>When the build completes, an email is sent out using the send-qa-email script in the
61 <filename>yocto-autobuilder-helper</filename> repository to the list of people
62 configured for that release. Release builds are placed into a directory in <link
63 linkend="">https://autobuilder.yocto.io/pub/releases</link> on the Autobuilder which
64 is included in the email. The process from here is more manual and control is
65 effectively passed to release engineering. The next steps include:<itemizedlist>
66 <listitem>
67 <para>QA teams respond to the email saying which tests they plan to run and when
68 the results will be available.</para>
69 </listitem>
70 <listitem>
71 <para>QA teams run their tests and share their results in the yocto-
72 testresults-contrib repository, along with a summary of their findings.
73 </para>
74 </listitem>
75 <listitem>
76 <para>Release engineering prepare the release as per their process. </para>
77 </listitem>
78 <listitem>
79 <para>Test results from the QA teams are included into the release in separate
80 directories and also uploaded to the yocto-testresults repository alongside
81 the other test results for the given revision.</para>
82 </listitem>
83 <listitem>
84 <para>The QA report in the final release is regenerated using resulttool to
85 include the new test results and the test summaries from the teams (as
86 headers to the generated report).</para>
87 </listitem>
88 <listitem>
89 <para>The release is checked against the release checklist and release readiness
90 criteria.</para>
91 </listitem>
92 <listitem>
93 <para>A final decision on whether to release is made by the YP TSC who have
94 final oversight on release readiness.</para>
95 </listitem>
96 </itemizedlist></para>
97 </section>
98
99
100
101
102
103
104
105
106</chapter>
107<!--
108vim: expandtab tw=80 ts=4
109-->
diff --git a/documentation/test-manual/test-manual-understand-autobuilder.xml b/documentation/test-manual/test-manual-understand-autobuilder.xml
new file mode 100644
index 0000000000..7541305350
--- /dev/null
+++ b/documentation/test-manual/test-manual-understand-autobuilder.xml
@@ -0,0 +1,312 @@
1<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
2"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
3[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
4
5<chapter id='test-manual-understand-autobuilder'>
6
7<title>Understanding the Yocto Project Autobuilder</title>
8 <section>
9 <title>Execution Flow within the Autobuilder</title>
10 <para>The “a-full” and “a-quick” targets are the usual entry points into the Autobuilder and
11 it makes sense to follow the process through the system starting there. This is best
12 visualised from the Autobuilder Console view (<link linkend=""
13 >https://autobuilder.yoctoproject.org/typhoon/#/console</link>). </para>
14 <para>Each item along the top of that view represents some “target build” and these targets
15 are all run in parallel. The ‘full’ build will trigger the majority of them, the “quick”
16 build will trigger some subset of them. The Autobuilder effectively runs whichever
17 configuration is defined for each of those targets on a seperate buildbot worker. To
18 understand the configuration, you need to look at the entry on
19 <filename>config.json</filename> file within the
20 <filename>yocto-autobuilder-helper</filename> repository. The targets are defined in
21 the ‘overrides’ section, a quick example could be qemux86-64 which looks
22 like:<literallayout>
23 "qemux86-64" : {
24 "MACHINE" : "qemux86-64",
25 "TEMPLATE" : "arch-qemu",
26 "step1" : {
27 "extravars" : [
28 "IMAGE_FSTYPES_append = ' wic wic.bmap'"
29 ]
30 }
31 },
32 </literallayout>And
33 to expand that, you need the “arch-qemu” entry from the “templates” section, which looks
34 like:<literallayout>
35 "arch-qemu" : {
36 "BUILDINFO" : true,
37 "BUILDHISTORY" : true,
38 "step1" : {
39 "BBTARGETS" : "core-image-sato core-image-sato-dev core-image-sato-sdk core-image-minimal core-image-minimal-dev core-image-sato:do_populate_sdk",
40 "SANITYTARGETS" : "core-image-minimal:do_testimage core-image-sato:do_testimage core-image-sato-sdk:do_testimage core-image-sato:do_testsdk"
41 },
42 "step2" : {
43 "SDKMACHINE" : "x86_64",
44 "BBTARGETS" : "core-image-sato:do_populate_sdk core-image-minimal:do_populate_sdk_ext core-image-sato:do_populate_sdk_ext",
45 "SANITYTARGETS" : "core-image-sato:do_testsdk core-image-minimal:do_testsdkext core-image-sato:do_testsdkext"
46 },
47 "step3" : {
48 "BUILDHISTORY" : false,
49 "EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; DISPLAY=:1 oe-selftest ${HELPERSTMACHTARGS} -j 15"],
50 "ADDLAYER" : ["${BUILDDIR}/../meta-selftest"]
51 }
52 },
53 </literallayout>Combining
54 these two entries you can see that “qemux86-64” is a three step build where the “bitbake
55 BBTARGETS” would be run, then “bitbake SANITYTARGETS” for each step; all for
56 MACHINE=”qemx86-64” but with differing SDKMACHINE settings. In step 1 an extra variable
57 is added to the <filename>auto.conf</filename> file to enable wic image
58 generation.</para>
59 <para>While not every detail of this is covered here, you can see how the templating
60 mechanism allows quite complex configurations to be built up yet allows duplication and
61 repetition to be kept to a minimum.</para>
62 <para>The different build targets are designed to allow for parallelisation, so different
63 machines are usually built in parallel, operations using the same machine and metadata
64 are built sequentially, with the aim of trying to optimise build efficiency as much as
65 possible.</para>
66 <para>The <filename>config.json</filename> file is processed by the scripts in the Helper
67 repository in the <filename>scripts</filename> directory. The following section details
68 how this works.</para>
69 </section>
70
71 <section id='test-autobuilder-target-exec-overview'>
72 <title>Autobuilder Target Execution Overview</title>
73
74 <para>For each given target in a build, the Autobuilder executes several steps. These are
75 configured in <filename>yocto-autobuilder2/builders.py</filename> and roughly consist
76 of: <orderedlist>
77 <listitem id='test-list-tgt-exec-clobberdir'>
78 <para><emphasis>Run <filename>clobberdir</filename></emphasis></para>
79 <para>This cleans out any previous build. Old builds are left around to allow
80 easier debugging of failed builds. For additional information, see <link
81 linkend="test-clobberdir"><filename>clobberdir</filename></link>.</para>
82 </listitem>
83 <listitem>
84 <para><emphasis>Obtain yocto-autobuilder-helper</emphasis></para>
85 <para>This step clones the <filename>yocto-autobuilder-helper</filename> git
86 repository. This is necessary to prevent the requirement to maintain all the
87 release or project-specific code within Buildbot. The branch chosen matches
88 the release being built so we can support older releases and still make
89 changes in newer ones.</para>
90 </listitem>
91 <listitem>
92 <para><emphasis>Write layerinfo.json</emphasis></para>
93 <para>This transfers data in the Buildbot UI when the build was configured to
94 the Helper.</para>
95 </listitem>
96 <listitem>
97 <para><emphasis>Call scripts/shared-repo-unpack</emphasis></para>
98 <para>This is a call into the Helper scripts to set up a checkout of all the
99 pieces this build might need. It might clone the BitBake repository and the
100 OpenEmbedded-Core repository. It may clone the Poky repository, as well as
101 additional layers. It will use the data from the
102 <filename>layerinfo.json</filename> file to help understand the
103 configuration. It will also use a local cache of repositories to speed up
104 the clone checkouts. For additional information, see <link
105 linkend="test-autobuilder-clone-cache">Autobuilder Clone
106 Cache</link>.</para>
107 <para>This step has two possible modes of operation. If the build is part of a
108 parent build, its possible that all the repositories needed may already be
109 available, ready in a pre-prepared directory. An "a-quick" or "a-full" build
110 would prepare this before starting the other sub-target builds. This is done
111 for two reasons:<itemizedlist>
112 <listitem>
113 <para>the upstream may change during a build, for example, from a
114 forced push and this ensures we have matching content for the
115 whole build</para>
116 </listitem>
117 <listitem>
118 <para>if 15 Workers all tried to pull the same data from the same
119 repos, we can hit resource limits on upstream servers as they
120 can think they are under some kind of network attack</para>
121 </listitem>
122 </itemizedlist>This pre-prepared directory is shared among the Workers over
123 NFS. If the build is an individual build and there is no "shared" directory
124 available, it would clone from the cache and the upstreams as necessary.
125 This is considered the fallback mode.</para>
126 </listitem>
127 <listitem>
128 <para><emphasis>Call scripts/run-config</emphasis></para>
129 <para>This is another call into the Helper scripts where its expected that the
130 main functionality of this target will be executed.</para>
131 </listitem>
132 </orderedlist></para>
133 </section>
134 <section id='test-autobuilder-tech'>
135 <title>Autobuilder Technology</title>
136 <para>The Autobuilder has Yocto Project-specific functionality to allow builds to operate
137 with increased efficiency and speed.</para>
138 <section id='test-clobberdir'>
139 <title>clobberdir</title>
140 <para>When deleting files, the Autobuilder uses <filename>clobberdir</filename>, which
141 is a special script that moves files to a special location, rather than deleting
142 them. Files in this location are deleted by an <filename>rm</filename> command,
143 which is run under <filename>ionice -c 3</filename>. For example, the deletion only
144 happens when there is idle IO capacity on the Worker. The Autobuilder Worker Janitor
145 runs this deletion. See <link linkend="test-autobuilder-worker-janitor">Autobuilder
146 Worker Janitor</link>.</para>
147 </section>
148 <section id='test-autobuilder-clone-cache'>
149 <title>Autobuilder Clone Cache</title>
150 <para>Cloning repositories from scratch each time they are required was slow on the
151 Autobuilder. We therefore have a stash of commonly used repositories pre-cloned on
152 the Workers. Data is fetched from these during clones first, then "topped up" with
153 later revisions from any upstream when necesary. The cache is maintained by the
154 Autobuilder Worker Janitor. See <link linkend="test-autobuilder-worker-janitor"
155 >Autobuilder Worker Janitor</link>.</para>
156 </section>
157 <section id='test-autobuilder-worker-janitor'>
158 <title>Autobuilder Worker Janitor</title>
159 <para>This is a process running on each Worker that performs two basic operations,
160 including background file deletion at IO idle (see <link
161 linkend="test-list-tgt-exec-clobberdir">Target Execution: clobberdir</link>) and
162 maintainenance of a cache of cloned repositories to improve the speed the system can
163 checkout repositories.</para>
164 </section>
165 <section id='test-shared-dl-dir'>
166 <title>Shared DL_DIR</title>
167 <para>The Workers are all connected over NFS which allows DL_DIR to be shared between
168 them. This reduces network accesses from the system and allows the build to be sped
169 up. Usage of the directory within the build system is designed to be able to be
170 shared over NFS.</para>
171 </section>
172 <section id='test-shared-sstate-cache'>
173 <title>Shared SSTATE_DIR</title>
174 <para>The Workers are all connected over NFS which allows the
175 <filename>sstate</filename> directory to be shared between them. This means once
176 a Worker has built an artefact, all the others can benefit from it. Usage of the
177 directory within the directory is designed for sharing over NFS.</para>
178 </section>
179 <section id='test-resulttool'>
180 <title>Resulttool</title>
181 <para>All of the different tests run as part of the build generate output into
182 <filename>testresults.json</filename> files. This allows us to determine which
183 tests ran in a given build and their status. Additional information, such as failure
184 logs or the time taken to run the tests, may also be included.</para>
185 <para>Resulttool is part of OpenEmbedded-Core and is used to manipulate these json
186 results files. It has the ability to merge files together, display reports of the
187 test results and compare different result files.</para>
188 <para>For details, see <link linkend=""
189 >https://wiki.yoctoproject.org/wiki/Resulttool</link>.</para>
190 </section>
191 </section>
192 <section id='test-run-config-tgt-execution'>
193 <title>run-config Target Execution</title>
194 <para>The <filename>scripts/run-config</filename> execution is where most of the work within
195 the Autobuilder happens. It runs through a number of steps; the first are general setup
196 steps that are run once and include:<orderedlist>
197 <listitem>
198 <para>Set up any <filename>buildtools-tarball</filename> if configured.</para>
199 </listitem>
200 <listitem>
201 <para>Call "buildhistory-init" if buildhistory is configured.</para>
202 </listitem>
203 </orderedlist></para>
204 <para>For each step that is configured in <filename>config.json</filename>, it will perform
205 the following:</para>
206 <para>
207 <remark>## WRITER's question: What does "logging in as stepXa" and others refer to
208 below? ##</remark>
209 <orderedlist>
210 <listitem id="test-run-config-add-layers-step">
211 <para dir="ltr">Add any layers that are specified using the
212 <filename>bitbake-layers add-layer</filename> command (logging as
213 stepXa)</para>
214 </listitem>
215 <listitem>
216 <para dir="ltr">Call the <filename>scripts/setup-config</filename> script to
217 generate the necessary <filename>auto.conf</filename> configuration file for
218 the build</para>
219 </listitem>
220 <listitem>
221 <para dir="ltr">Run the <filename>bitbake BBTARGETS</filename> command (logging
222 as stepXb)</para>
223 </listitem>
224 <listitem>
225 <para dir="ltr">Run the <filename>bitbake SANITYTARGETS</filename> command
226 (logging as stepXc)</para>
227 </listitem>
228 <listitem>
229 <para dir="ltr">Run the <filename>EXTRACMDS</filename> command, which are run
230 within the BitBake build environment (logging as stepXd)</para>
231 </listitem>
232 <listitem>
233 <para dir="ltr">Run the <filename>EXTRAPLAINCMDS</filename> command(s), which
234 are run outside the BitBake build environment (logging as stepXd)</para>
235 </listitem>
236 <listitem>
237 <para dir="ltr">Remove any layers added in <link
238 linkend="test-run-config-add-layers-step">step 1</link> using the
239 <filename>bitbake-layers remove-layer</filename> command (logging as
240 stepXa)</para>
241 </listitem>
242 </orderedlist>
243 </para>
244 <para>Once the execution steps above complete, <filename>run-config</filename> executes a
245 set of post-build steps, including:<orderedlist>
246 <listitem>
247 <para dir="ltr">Call <filename>scripts/publish-artifacts</filename> to collect
248 any output which is to be saved from the build.</para>
249 </listitem>
250 <listitem>
251 <para dir="ltr">Call <filename>scripts/collect-results</filename> to collect any
252 test results to be saved from the build.</para>
253 </listitem>
254 <listitem>
255 <para dir="ltr">Call <filename>scripts/upload-error-reports</filename> to send
256 any error reports generated to the remote server.</para>
257 </listitem>
258 <listitem>
259 <para dir="ltr">Cleanup the build directory using <link
260 linkend="test-clobberdir"><filename>clobberdir</filename></link> if the
261 build was successful, else rename it to “build-renamed” for potential future
262 debugging.</para>
263 </listitem>
264 </orderedlist></para>
265 </section>
266 <section id='test-deploying-yp-autobuilder'>
267 <title>Deploying Yocto Autobuilder</title>
268 <para>The most up to date information about how to setup and deploy your own Autbuilder can
269 be found in README.md in the <filename>yocto-autobuilder2</filename> repository.</para>
270 <para>We hope that people can use the <filename>yocto-autobuilder2</filename> code directly
271 but it is inevitable that users will end up needing to heavily customise the
272 <filename>yocto-autobuilder-helper</filename> repository, particularly the
273 <filename>config.json</filename> file as they will want to define their own test
274 matrix.</para>
275 <para>The Autobuilder supports wo customization options: <itemizedlist>
276 <listitem>
277 <para>variable substitution</para>
278 </listitem>
279 <listitem>
280 <para>overlaying configuration files</para>
281 </listitem>
282 </itemizedlist>The standard <filename>config.json</filename> minimally attempts to allow
283 substitution of the paths. The Helper script repository includes a
284 <filename>local-example.json</filename> file to show how you could override these
285 from a separate configuration file. Pass the following into the environment of the
286 Autobuilder:<literallayout>
287 $ ABHELPER_JSON="config.json local-example.json"
288 </literallayout>As
289 another example, you could also pass the following into the
290 environment:<literallayout>
291 $ ABHELPER_JSON="config.json <replaceable>/some/location/</replaceable>local.json"
292 </literallayout>One
293 issue users often run into is validation of the <filename>config.json</filename> files.
294 A tip for minimizing issues from invalid json files is to use a Git
295 <filename>pre-commit-hook.sh</filename> script to verify the JSON file before
296 committing it. Create a symbolic link as
297 follows:<literallayout>
298 $ ln -s ../../scripts/pre-commit-hook.sh .git/hooks/pre-commit
299 </literallayout></para>
300 </section>
301
302
303
304
305
306
307
308
309</chapter>
310<!--
311vim: expandtab tw=80 ts=4
312-->
diff --git a/documentation/test-manual/test-manual.xml b/documentation/test-manual/test-manual.xml
new file mode 100755
index 0000000000..9d3c0354de
--- /dev/null
+++ b/documentation/test-manual/test-manual.xml
@@ -0,0 +1,103 @@
1<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
2"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
3[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
4
5<book id='test-manual' lang='en'
6 xmlns:xi="http://www.w3.org/2003/XInclude"
7 xmlns="http://docbook.org/ns/docbook"
8 >
9 <bookinfo>
10
11 <mediaobject>
12 <imageobject>
13 <imagedata fileref='figures/test-manual-title.png'
14 format='SVG'
15 align='left' scalefit='1' width='100%'/>
16 </imageobject>
17 </mediaobject>
18
19 <title>
20 Yocto Project Test Environment Manual
21 </title>
22
23 <authorgroup>
24 <author>
25 <affiliation>
26 <orgname>&ORGNAME;</orgname>
27 </affiliation>
28 <email>&ORGEMAIL;</email>
29 </author>
30 </authorgroup>
31
32 <revhistory>
33 <revision>
34 <revnumber>3.1.1</revnumber>
35 <date>TBD</date>
36 <revremark>DRAFT - Work-in-Progress - posted June 16, 2020</revremark>
37 </revision>
38 </revhistory>
39
40 <copyright>
41 <year>&COPYRIGHT_YEAR;</year>
42 <holder>Linux Foundation</holder>
43 </copyright>
44
45 <legalnotice>
46 <para>
47 Permission is granted to copy, distribute and/or modify this document under
48 the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">
49 Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by
50 Creative Commons.
51 </para>
52 <note><title>Manual Notes</title>
53 <itemizedlist>
54 <listitem><para>
55 This version of the
56 <emphasis>Yocto Project Test Environment Manual</emphasis>
57 is for the &YOCTO_DOC_VERSION; release of the
58 Yocto Project.
59 To be sure you have the latest version of the manual
60 for this release, go to the
61 <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
62 and select the manual from that site.
63 Manuals from the site are more up-to-date than manuals
64 derived from the Yocto Project released TAR files.
65 </para></listitem>
66 <listitem><para>
67 If you located this manual through a web search, the
68 version of the manual might not be the one you want
69 (e.g. the search might have returned a manual much
70 older than the Yocto Project version with which you
71 are working).
72 You can see all Yocto Project major releases by
73 visiting the
74 <ulink url='&YOCTO_WIKI_URL;/wiki/Releases'>Releases</ulink>
75 page.
76 If you need a version of this manual for a different
77 Yocto Project release, visit the
78 <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
79 and select the manual set by using the
80 "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
81 pull-down menus.
82 </para></listitem>
83 <listitem><para>
84 To report any inaccuracies or problems with this
85 manual, send an email to the Yocto Project
86 discussion group at
87 <filename>yocto@yoctoproject.com</filename> or log into
88 the freenode <filename>#yocto</filename> channel.
89 </para></listitem>
90 </itemizedlist>
91 </note>
92 </legalnotice>
93
94 </bookinfo>
95
96 <xi:include href="test-manual-intro.xml"/>
97 <xi:include href="test-manual-test-process.xml"/>
98 <xi:include href="test-manual-understand-autobuilder.xml"/>
99
100</book>
101<!--
102vim: expandtab tw=80 ts=4
103-->
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-18 21:30:25 +0000