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

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
"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
console view to see where me manage most test-related items, available
at: :yocto_ab:`/typhoon/#/console`.
:yocto_ab:`console view </typhoon/#/console>` to see where we manage most
test-related items.
Builds are triggered manually when the test branches are ready. The
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
reasons, in particular, to ensure the current ``master`` branch does
build, but also to keep ``yocto-testresults``
(:yocto_git:`/yocto-testresults/`),
buildhistory
(:yocto_git:`/poky-buildhistory/`), and
our sstate up to date. On the weekend, there is a master-next build
build, but also to keep (:yocto_git:`yocto-testresults </yocto-testresults/>`),
(:yocto_git:`buildhistory </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
run targets.
Performance builds (``buildperf-\*`` targets in the console) are triggered
separately every six hours and automatically push their results to the
buildstats repository at:
:yocto_git:`/yocto-buildstats/`.
:yocto_git:`buildstats </yocto-buildstats/>` repository.
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
@ -69,10 +66,10 @@ configured to generate and publish artifacts and the milestone number,
version, release candidate number and other information is entered. The
box to "generate an email to QA" is also checked.
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
people configured for that release. Release builds are placed into a
directory in https://autobuilder.yocto.io/pub/releases on the
When the build completes, an email is sent out using the ``send-qa-email``
script in the :yocto_git:`yocto-autobuilder-helper </yocto-autobuilder-helper>`
repository to the list of people configured for that release. Release builds
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
more manual and control is effectively passed to release engineering.
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
when the results will be available.
- QA teams run their tests and share their results in the yocto-
testresults-contrib repository, along with a summary of their
findings.
- QA teams run their tests and share their results in the
:yocto_git:`yocto-testresults-contrib </yocto-testresults-contrib>`
repository, along with a summary of their findings.
- Release engineering prepare the release as per their process.
- 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.
- The QA report in the final release is regenerated using resulttool to

View File

@ -9,8 +9,8 @@ Execution Flow within the Autobuilder
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
starting there. This is best visualized from the Autobuilder Console
view (:yocto_ab:`/typhoon/#/console`).
starting there. This is best visualized from the :yocto_ab:`Autobuilder
Console view </typhoon/#/console>`.
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
@ -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
each of those targets on a separate buildbot worker. To understand the
configuration, you need to look at the entry on ``config.json`` file
within the ``yocto-autobuilder-helper`` repository. The targets are
defined in the overrides' section, a quick example could be qemux86-64
which looks like::
within the :yocto_git:`yocto-autobuilder-helper </yocto-autobuilder-helper>`
repository. The targets are defined in the ``overrides`` section, a quick
example could be ``qemux86-64`` which looks like::
"qemux86-64" : {
"MACHINE" : "qemux86-64",
@ -88,9 +88,9 @@ roughly consist of:
#. *Obtain yocto-autobuilder-helper*
This step clones the ``yocto-autobuilder-helper`` git repository.
This is necessary to prevent the requirement to maintain all the
release or project-specific code within Buildbot. The branch chosen
This step clones the :yocto_git:`yocto-autobuilder-helper </yocto-autobuilder-helper>`
git repository. This is necessary to avoid the requirement to maintain all
the release or project-specific code within Buildbot. The branch chosen
matches the release being built so we can support older releases and
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
Autobuilder can be found in README.md in the ``yocto-autobuilder2``
repository.
Autobuilder can be found in :yocto_git:`README.md </yocto-autobuilder2/tree/README.md>`
in the :yocto_git:`yocto-autobuilder2 </yocto-autobuilder2>` repository.
We hope that people can use the ``yocto-autobuilder2`` code directly but
it is inevitable that users will end up needing to heavily customise the
``yocto-autobuilder-helper`` repository, particularly the
``config.json`` file as they will want to define their own test matrix.
We hope that people can use the :yocto_git:`yocto-autobuilder2 </yocto-autobuilder2>`
code directly but it is inevitable that users will end up needing to heavily
customize the :yocto_git:`yocto-autobuilder-helper </yocto-autobuilder-helper>`
repository, particularly the ``config.json`` file as they will want to define
their own test matrix.
The Autobuilder supports two customization options: