Lines Matching +full:step +full:- +full:up
1 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
10 The "a-full" and "a-quick" targets are the usual entry points into the
21 within the ``yocto-autobuilder-helper`` repository. The targets are
22 defined in the ‘overrides' section, a quick example could be qemux86-64
25 "qemux86-64" : {
26 "MACHINE" : "qemux86-64",
27 "TEMPLATE" : "arch-qemu",
35 And to expand that, you need the "arch-qemu" entry from
38 "arch-qemu" : {
42 …"BBTARGETS" : "core-image-sato core-image-sato-dev core-image-sato-sdk core-image-minimal core-ima…
43 …"SANITYTARGETS" : "core-image-minimal:do_testimage core-image-sato:do_testimage core-image-sato-sd…
47 …"BBTARGETS" : "core-image-sato:do_populate_sdk core-image-minimal:do_populate_sdk_ext core-image-s…
48 …"SANITYTARGETS" : "core-image-sato:do_testsdk core-image-minimal:do_testsdkext core-image-sato:do_…
52 … "EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; DISPLAY=:1 oe-selftest ${HELPERSTMACHTARGS} -j 15"],
53 "ADDLAYER" : ["${BUILDDIR}/../meta-selftest"]
57 Combining these two entries you can see that "qemux86-64" is a three step build where the
58 ``bitbake BBTARGETS`` would be run, then ``bitbake SANITYTARGETS`` for each step; all for
59 ``MACHINE="qemx86-64"`` but with differing SDKMACHINE settings. In step
64 template mechanism allows quite complex configurations to be built up
80 steps. These are configured in ``yocto-autobuilder2/builders.py`` and
87 see :ref:`test-manual/understand-autobuilder:clobberdir`.
89 #. *Obtain yocto-autobuilder-helper*
91 This step clones the ``yocto-autobuilder-helper`` git repository.
93 release or project-specific code within Buildbot. The branch chosen
102 #. *Call scripts/shared-repo-unpack*
104 This is a call into the Helper scripts to set up a checkout of all
106 repository and the OpenEmbedded-Core repository. It may clone the
110 speed up the clone checkouts. For additional information, see
111 :ref:`test-manual/understand-autobuilder:Autobuilder Clone Cache`.
113 This step has two possible modes of operation. If the build is part
115 already be available, ready in a pre-prepared directory. An "a-quick"
116 or "a-full" build would prepare this before starting the other
117 sub-target builds. This is done for two reasons:
119 - the upstream may change during a build, for example, from a forced
122 - if 15 Workers all tried to pull the same data from the same repos,
126 This pre-prepared directory is shared among the Workers over NFS. If
131 #. *Call scripts/run-config*
139 The Autobuilder has Yocto Project-specific functionality to allow builds
143 ----------
148 which is run under ``ionice -c 3``. For example, the deletion only
150 Worker Janitor runs this deletion. See :ref:`test-manual/understand-autobuilder:Autobuilder Worker …
153 -----------------------
157 repositories pre-cloned on the Workers. Data is fetched from these
158 during clones first, then "topped up" with later revisions from any
160 Worker Janitor. See :ref:`test-manual/understand-autobuilder:Autobuilder Worker Janitor`.
163 --------------------------
166 operations, including background file deletion at IO idle (see :ref:`test-manual/understand-autobui…
171 -------------
175 the build to be sped up. Usage of the directory within the build system
179 -----------------
187 ----------
194 Resulttool is part of OpenEmbedded-Core and is used to manipulate these
200 run-config Target Execution
203 The ``scripts/run-config`` execution is where most of the work within
207 #. Set up any ``buildtools-tarball`` if configured.
209 #. Call "buildhistory-init" if buildhistory is configured.
211 For each step that is configured in ``config.json``, it will perform the
215 ``bitbake-layers add-layer`` command (logging as stepXa)
217 #. Call the ``scripts/setup-config`` script to generate the necessary
230 #. Remove any layers added in step
231 1 using the ``bitbake-layers remove-layer`` command (logging as stepXa)
233 Once the execution steps above complete, ``run-config`` executes a set
234 of post-build steps, including:
236 #. Call ``scripts/publish-artifacts`` to collect any output which is to
239 #. Call ``scripts/collect-results`` to collect any test results to be
242 #. Call ``scripts/upload-error-reports`` to send any error reports
246 :ref:`test-manual/understand-autobuilder:clobberdir` if the build was successful,
247 else rename it to "build-renamed" for potential future debugging.
252 The most up to date information about how to setup and deploy your own
253 Autobuilder can be found in README.md in the ``yocto-autobuilder2``
256 We hope that people can use the ``yocto-autobuilder2`` code directly but
257 it is inevitable that users will end up needing to heavily customise the
258 ``yocto-autobuilder-helper`` repository, particularly the
263 - variable substitution
265 - overlaying configuration files
269 ``local-example.json`` file to show how you could override these from a
273 $ ABHELPER_JSON="config.json local-example.json"
282 ``pre-commit-hook.sh`` script to verify the JSON file before committing
285 $ ln -s ../../scripts/pre-commit-hook.sh .git/hooks/pre-commit