mirror of
git://git.yoctoproject.org/poky.git
synced 2025-07-19 12:59:02 +02: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:
parent
d9be74b13f
commit
bd8f3acd14
|
@ -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
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
Loading…
Reference in New Issue
Block a user