mirror of
https://git.yoctoproject.org/poky
synced 2026-04-18 12:32:12 +02:00
test-manual: remove unused labels
(From yocto-docs rev: 3f7a065dafd24a3c1e6b7f68b522352606f8fd7b) Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
committed by
Richard Purdie
parent
043592a585
commit
95b2d8a7fd
@@ -4,8 +4,6 @@
|
||||
The Yocto Project Test Environment Manual
|
||||
*****************************************
|
||||
|
||||
.. _test-welcome:
|
||||
|
||||
Welcome
|
||||
=======
|
||||
|
||||
@@ -45,8 +43,6 @@ engineers:
|
||||
Jenkins, or others. This repository has a branch per release of the
|
||||
project defining the tests to run on a per release basis.
|
||||
|
||||
.. _test-yocto-project-autobuilder-overview:
|
||||
|
||||
Yocto Project Autobuilder Overview
|
||||
==================================
|
||||
|
||||
@@ -88,8 +84,6 @@ topology that includes a controller and a cluster of workers:
|
||||
.. image:: figures/ab-test-cluster.png
|
||||
:align: center
|
||||
|
||||
.. _test-project-tests:
|
||||
|
||||
Yocto Project Tests - Types of Testing Overview
|
||||
===============================================
|
||||
|
||||
@@ -169,8 +163,6 @@ thefollowing types of tests:
|
||||
those new versions. If so, this target emails the maintainers with a
|
||||
patch to let them know this is possible.
|
||||
|
||||
.. _test-test-mapping:
|
||||
|
||||
How Tests Map to Areas of Code
|
||||
==============================
|
||||
|
||||
@@ -326,8 +318,6 @@ directory at ``meta/lib/oeqa/selftest/cases`` directory.
|
||||
For oe-selftest. bitbake testcases reside in the ``lib/bb/tests/``
|
||||
directory.
|
||||
|
||||
.. _bitbake-selftest-example:
|
||||
|
||||
``bitbake-selftest``
|
||||
--------------------
|
||||
|
||||
@@ -354,8 +344,6 @@ Bitbake selftests are straightforward python unittest. Refer to the
|
||||
Python unittest documentation for additional information on writing
|
||||
these tests at: https://docs.python.org/3/library/unittest.html.
|
||||
|
||||
.. _oe-selftest-example:
|
||||
|
||||
``oe-selftest``
|
||||
---------------
|
||||
|
||||
@@ -399,8 +387,6 @@ builds. There is no data store available for these tests since the tests
|
||||
launch the ``bitbake`` command and exist outside of its context. As a
|
||||
result, common bitbake library functions (bb.\*) are also unavailable.
|
||||
|
||||
.. _testimage-example:
|
||||
|
||||
``testimage``
|
||||
-------------
|
||||
|
||||
@@ -429,8 +415,6 @@ To ensure certain test or package dependencies are met, you can use the
|
||||
in this example would only make sense if python3-core is installed in
|
||||
the image.
|
||||
|
||||
.. _testsdk_ext-example:
|
||||
|
||||
``testsdk_ext``
|
||||
---------------
|
||||
|
||||
@@ -463,8 +447,6 @@ In this example, the ``devtool``
|
||||
command is tested to see whether a sample application can be built with
|
||||
the ``devtool build`` command within the eSDK.
|
||||
|
||||
.. _testsdk-example:
|
||||
|
||||
``testsdk``
|
||||
-----------
|
||||
|
||||
@@ -488,8 +470,6 @@ In this example, if nativesdk-python3-core has been installed into the SDK, the
|
||||
the python3 interpreter with a basic command to check it is working
|
||||
correctly. The test would only run if python3 is installed in the SDK.
|
||||
|
||||
.. _oe-build-perf-test-example:
|
||||
|
||||
``oe-build-perf-test``
|
||||
----------------------
|
||||
|
||||
@@ -517,8 +497,6 @@ This example shows how three specific parsing timings are
|
||||
measured, with and without various caches, to show how BitBake's parsing
|
||||
performance trends over time.
|
||||
|
||||
.. _test-writing-considerations:
|
||||
|
||||
Considerations When Writing Tests
|
||||
=================================
|
||||
|
||||
|
||||
@@ -4,8 +4,6 @@
|
||||
Project Testing and Release Process
|
||||
***********************************
|
||||
|
||||
.. _test-daily-devel:
|
||||
|
||||
Day to Day Development
|
||||
======================
|
||||
|
||||
|
||||
@@ -73,8 +73,6 @@ The ``config.json`` file is processed by the scripts in the Helper
|
||||
repository in the ``scripts`` directory. The following section details
|
||||
how this works.
|
||||
|
||||
.. _test-autobuilder-target-exec-overview:
|
||||
|
||||
Autobuilder Target Execution Overview
|
||||
=====================================
|
||||
|
||||
@@ -135,16 +133,12 @@ roughly consist of:
|
||||
This is another call into the Helper scripts where its expected that
|
||||
the main functionality of this target will be executed.
|
||||
|
||||
.. _test-autobuilder-tech:
|
||||
|
||||
Autobuilder Technology
|
||||
======================
|
||||
|
||||
The Autobuilder has Yocto Project-specific functionality to allow builds
|
||||
to operate with increased efficiency and speed.
|
||||
|
||||
.. _test-clobberdir:
|
||||
|
||||
clobberdir
|
||||
----------
|
||||
|
||||
@@ -155,8 +149,6 @@ which is run under ``ionice -c 3``. For example, the deletion only
|
||||
happens when there is idle IO capacity on the Worker. The Autobuilder
|
||||
Worker Janitor runs this deletion. See :ref:`test-manual/test-manual-understand-autobuilder:Autobuilder Worker Janitor`.
|
||||
|
||||
.. _test-autobuilder-clone-cache:
|
||||
|
||||
Autobuilder Clone Cache
|
||||
-----------------------
|
||||
|
||||
@@ -167,8 +159,6 @@ during clones first, then "topped up" with later revisions from any
|
||||
upstream when necessary. The cache is maintained by the Autobuilder
|
||||
Worker Janitor. See :ref:`test-manual/test-manual-understand-autobuilder:Autobuilder Worker Janitor`.
|
||||
|
||||
.. _test-autobuilder-worker-janitor:
|
||||
|
||||
Autobuilder Worker Janitor
|
||||
--------------------------
|
||||
|
||||
@@ -177,8 +167,6 @@ operations, including background file deletion at IO idle (see :ref:`test-manual
|
||||
maintainenance of a cache of cloned repositories to improve the speed
|
||||
the system can checkout repositories.
|
||||
|
||||
.. _test-shared-dl-dir:
|
||||
|
||||
Shared DL_DIR
|
||||
-------------
|
||||
|
||||
@@ -187,8 +175,6 @@ between them. This reduces network accesses from the system and allows
|
||||
the build to be sped up. Usage of the directory within the build system
|
||||
is designed to be able to be shared over NFS.
|
||||
|
||||
.. _test-shared-sstate-cache:
|
||||
|
||||
Shared SSTATE_DIR
|
||||
-----------------
|
||||
|
||||
@@ -197,8 +183,6 @@ directory to be shared between them. This means once a Worker has built
|
||||
an artifact, all the others can benefit from it. Usage of the directory
|
||||
within the directory is designed for sharing over NFS.
|
||||
|
||||
.. _test-resulttool:
|
||||
|
||||
Resulttool
|
||||
----------
|
||||
|
||||
@@ -213,8 +197,6 @@ reports of the test results and compare different result files.
|
||||
|
||||
For details, see :yocto_wiki:`/wiki/Resulttool`.
|
||||
|
||||
.. _test-run-config-tgt-execution:
|
||||
|
||||
run-config Target Execution
|
||||
===========================
|
||||
|
||||
@@ -264,8 +246,6 @@ of post-build steps, including:
|
||||
:ref:`test-manual/test-manual-understand-autobuilder:clobberdir` if the build was successful,
|
||||
else rename it to "build-renamed" for potential future debugging.
|
||||
|
||||
.. _test-deploying-yp-autobuilder:
|
||||
|
||||
Deploying Yocto Autobuilder
|
||||
===========================
|
||||
|
||||
|
||||
Reference in New Issue
Block a user