1
0
mirror of https://git.yoctoproject.org/poky synced 2026-06-01 13:09:50 +00:00

test-manual: add or improve hyperlinks

(From yocto-docs rev: db88611b8d80ce909afa697766123001fa4e5741)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Michael Opdenacker
2023-12-06 16:48:49 +01:00
committed by Richard Purdie
parent d9be74b13f
commit bd8f3acd14
2 changed files with 30 additions and 31 deletions
+15 -17
View File
@@ -20,8 +20,8 @@ helps review and test patches and this is his testing tree).
We have two broad categories of test builds, including "full" and We have two broad categories of test builds, including "full" and
"quick". On the Autobuilder, these can be seen as "a-quick" and "quick". On the Autobuilder, these can be seen as "a-quick" and
"a-full", simply for ease of sorting in the UI. Use our Autobuilder "a-full", simply for ease of sorting in the UI. Use our Autobuilder
console view to see where me manage most test-related items, available :yocto_ab:`console view </typhoon/#/console>` to see where we manage most
at: :yocto_ab:`/typhoon/#/console`. test-related items.
Builds are triggered manually when the test branches are ready. The Builds are triggered manually when the test branches are ready. The
builds are monitored by the SWAT team. For additional information, see builds are monitored by the SWAT team. For additional information, see
@@ -34,18 +34,15 @@ which the result was required.
The Autobuilder does build the ``master`` branch once daily for several The Autobuilder does build the ``master`` branch once daily for several
reasons, in particular, to ensure the current ``master`` branch does reasons, in particular, to ensure the current ``master`` branch does
build, but also to keep ``yocto-testresults`` build, but also to keep (:yocto_git:`yocto-testresults </yocto-testresults/>`),
(:yocto_git:`/yocto-testresults/`), (:yocto_git:`buildhistory </poky-buildhistory/>`), and
buildhistory our sstate up to date. On the weekend, there is a ``master-next`` build
(:yocto_git:`/poky-buildhistory/`), and
our sstate up to date. On the weekend, there is a master-next build
instead to ensure the test results are updated for the less frequently instead to ensure the test results are updated for the less frequently
run targets. run targets.
Performance builds (``buildperf-\*`` targets in the console) are triggered Performance builds (``buildperf-\*`` targets in the console) are triggered
separately every six hours and automatically push their results to the separately every six hours and automatically push their results to the
buildstats repository at: :yocto_git:`buildstats </yocto-buildstats/>` repository.
:yocto_git:`/yocto-buildstats/`.
The "quick" targets have been selected to be the ones which catch the The "quick" targets have been selected to be the ones which catch the
most failures or give the most valuable data. We run "fast" ptests in most failures or give the most valuable data. We run "fast" ptests in
@@ -69,10 +66,10 @@ configured to generate and publish artifacts and the milestone number,
version, release candidate number and other information is entered. The version, release candidate number and other information is entered. The
box to "generate an email to QA" is also checked. box to "generate an email to QA" is also checked.
When the build completes, an email is sent out using the send-qa-email When the build completes, an email is sent out using the ``send-qa-email``
script in the ``yocto-autobuilder-helper`` repository to the list of script in the :yocto_git:`yocto-autobuilder-helper </yocto-autobuilder-helper>`
people configured for that release. Release builds are placed into a repository to the list of people configured for that release. Release builds
directory in https://autobuilder.yocto.io/pub/releases on the are placed into a directory in https://autobuilder.yocto.io/pub/releases on the
Autobuilder which is included in the email. The process from here is Autobuilder which is included in the email. The process from here is
more manual and control is effectively passed to release engineering. more manual and control is effectively passed to release engineering.
The next steps include: The next steps include:
@@ -80,14 +77,15 @@ The next steps include:
- QA teams respond to the email saying which tests they plan to run and - QA teams respond to the email saying which tests they plan to run and
when the results will be available. when the results will be available.
- QA teams run their tests and share their results in the yocto- - QA teams run their tests and share their results in the
testresults-contrib repository, along with a summary of their :yocto_git:`yocto-testresults-contrib </yocto-testresults-contrib>`
findings. repository, along with a summary of their findings.
- Release engineering prepare the release as per their process. - Release engineering prepare the release as per their process.
- Test results from the QA teams are included into the release in - Test results from the QA teams are included into the release in
separate directories and also uploaded to the yocto-testresults separate directories and also uploaded to the
:yocto_git:`yocto-testresults </yocto-testresults>`
repository alongside the other test results for the given revision. repository alongside the other test results for the given revision.
- The QA report in the final release is regenerated using resulttool to - The QA report in the final release is regenerated using resulttool to
@@ -9,8 +9,8 @@ Execution Flow within the Autobuilder
The "a-full" and "a-quick" targets are the usual entry points into the The "a-full" and "a-quick" targets are the usual entry points into the
Autobuilder and it makes sense to follow the process through the system Autobuilder and it makes sense to follow the process through the system
starting there. This is best visualized from the Autobuilder Console starting there. This is best visualized from the :yocto_ab:`Autobuilder
view (:yocto_ab:`/typhoon/#/console`). Console view </typhoon/#/console>`.
Each item along the top of that view represents some "target build" and Each item along the top of that view represents some "target build" and
these targets are all run in parallel. The 'full' build will trigger the these targets are all run in parallel. The 'full' build will trigger the
@@ -18,9 +18,9 @@ majority of them, the "quick" build will trigger some subset of them.
The Autobuilder effectively runs whichever configuration is defined for The Autobuilder effectively runs whichever configuration is defined for
each of those targets on a separate buildbot worker. To understand the each of those targets on a separate buildbot worker. To understand the
configuration, you need to look at the entry on ``config.json`` file configuration, you need to look at the entry on ``config.json`` file
within the ``yocto-autobuilder-helper`` repository. The targets are within the :yocto_git:`yocto-autobuilder-helper </yocto-autobuilder-helper>`
defined in the overrides' section, a quick example could be qemux86-64 repository. The targets are defined in the ``overrides`` section, a quick
which looks like:: example could be ``qemux86-64`` which looks like::
"qemux86-64" : { "qemux86-64" : {
"MACHINE" : "qemux86-64", "MACHINE" : "qemux86-64",
@@ -88,9 +88,9 @@ roughly consist of:
#. *Obtain yocto-autobuilder-helper* #. *Obtain yocto-autobuilder-helper*
This step clones the ``yocto-autobuilder-helper`` git repository. This step clones the :yocto_git:`yocto-autobuilder-helper </yocto-autobuilder-helper>`
This is necessary to prevent the requirement to maintain all the git repository. This is necessary to avoid the requirement to maintain all
release or project-specific code within Buildbot. The branch chosen the release or project-specific code within Buildbot. The branch chosen
matches the release being built so we can support older releases and matches the release being built so we can support older releases and
still make changes in newer ones. still make changes in newer ones.
@@ -251,13 +251,14 @@ Deploying Yocto Autobuilder
=========================== ===========================
The most up to date information about how to setup and deploy your own The most up to date information about how to setup and deploy your own
Autobuilder can be found in README.md in the ``yocto-autobuilder2`` Autobuilder can be found in :yocto_git:`README.md </yocto-autobuilder2/tree/README.md>`
repository. in the :yocto_git:`yocto-autobuilder2 </yocto-autobuilder2>` repository.
We hope that people can use the ``yocto-autobuilder2`` code directly but We hope that people can use the :yocto_git:`yocto-autobuilder2 </yocto-autobuilder2>`
it is inevitable that users will end up needing to heavily customise the code directly but it is inevitable that users will end up needing to heavily
``yocto-autobuilder-helper`` repository, particularly the customize the :yocto_git:`yocto-autobuilder-helper </yocto-autobuilder-helper>`
``config.json`` file as they will want to define their own test matrix. repository, particularly the ``config.json`` file as they will want to define
their own test matrix.
The Autobuilder supports two customization options: The Autobuilder supports two customization options: