blob: dfe51889e8c04c9849e59421dba9d938cba35075 [file] [log] [blame]
Andrew Geisslerf0343792020-11-18 10:42:21 -06001.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002
3**********************
4Concepts and Reference
5**********************
6
7In order to configure and use Toaster, you should understand some
8concepts and have some basic command reference material available. This
9final chapter provides conceptual information on layer sources,
10releases, and JSON configuration files. Also provided is a quick look at
11some useful ``manage.py`` commands that are Toaster-specific.
12Information on ``manage.py`` commands does exist across the Web and the
13information in this manual by no means attempts to provide a command
14comprehensive reference.
15
16Layer Source
17============
18
19In general, a "layer source" is a source of information about existing
20layers. In particular, we are concerned with layers that you can use
21with the Yocto Project and Toaster. This chapter describes a particular
22type of layer source called a "layer index."
23
24A layer index is a web application that contains information about a set
25of custom layers. A good example of an existing layer index is the
26OpenEmbedded Layer Index. A public instance of this layer index exists
27at http://layers.openembedded.org. You can find the code for this
Andrew Geissler09209ee2020-12-13 08:44:15 -060028layer index's web application at :yocto_git:`/layerindex-web/`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -050029
30When you tie a layer source into Toaster, it can query the layer source
31through a
32`REST <http://en.wikipedia.org/wiki/Representational_state_transfer>`__
33API, store the information about the layers in the Toaster database, and
34then show the information to users. Users are then able to view that
35information and build layers from Toaster itself without worrying about
36cloning or editing the BitBake layers configuration file
37``bblayers.conf``.
38
39Tying a layer source into Toaster is convenient when you have many
40custom layers that need to be built on a regular basis by a community of
41developers. In fact, Toaster comes pre-configured with the OpenEmbedded
42Metadata Index.
43
44.. note::
45
46 You do not have to use a layer source to use Toaster. Tying into a
47 layer source is optional.
48
Andrew Geisslerc9f78652020-09-18 14:11:35 -050049Setting Up and Using a Layer Source
50-----------------------------------
51
52To use your own layer source, you need to set up the layer source and
53then tie it into Toaster. This section describes how to tie into a layer
54index in a manner similar to the way Toaster ties into the OpenEmbedded
55Metadata Index.
56
57Understanding Your Layers
58~~~~~~~~~~~~~~~~~~~~~~~~~
59
60The obvious first step for using a layer index is to have several custom
61layers that developers build and access using the Yocto Project on a
62regular basis. This set of layers needs to exist and you need to be
63familiar with where they reside. You will need that information when you
64set up the code for the web application that "hooks" into your set of
65layers.
66
67For general information on layers, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -060068":ref:`overview-manual/yp-intro:the yocto project layer model`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -050069section in the Yocto Project Overview and Concepts Manual. For information on how
Andrew Geissler09209ee2020-12-13 08:44:15 -060070to create layers, see the ":ref:`dev-manual/common-tasks:understanding and creating layers`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -050071section in the Yocto Project Development Tasks Manual.
72
Andrew Geisslerc9f78652020-09-18 14:11:35 -050073Configuring Toaster to Hook Into Your Layer Index
74~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
75
76If you want Toaster to use your layer index, you must host the web
77application in a server to which Toaster can connect. You also need to
78give Toaster the information about your layer index. In other words, you
79have to configure Toaster to use your layer index. This section
80describes two methods by which you can configure and use your layer
81index.
82
83In the previous section, the code for the OpenEmbedded Metadata Index
84(i.e. http://layers.openembedded.org) was referenced. You can use
Andrew Geissler09209ee2020-12-13 08:44:15 -060085this code, which is at :yocto_git:`/layerindex-web/`, as a base to create
86your own layer index.
Andrew Geisslerc9f78652020-09-18 14:11:35 -050087
88Use the Administration Interface
89^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
90
91Access the administration interface through a browser by entering the
92URL of your Toaster instance and adding "``/admin``" to the end of the
93URL. As an example, if you are running Toaster locally, use the
94following URL::
95
96 http://127.0.0.1:8000/admin
97
98The administration interface has a "Layer sources" section that includes
99an "Add layer source" button. Click that button and provide the required
100information. Make sure you select "layerindex" as the layer source type.
101
102Use the Fixture Feature
103^^^^^^^^^^^^^^^^^^^^^^^
104
105The Django fixture feature overrides the default layer server when you
106use it to specify a custom URL. To use the fixture feature, create (or
107edit) the file ``bitbake/lib/toaster.orm/fixtures/custom.xml``, and then
108set the following Toaster setting to your custom URL:
109
110.. code-block:: xml
111
112 <?xml version="1.0" ?>
113 <django-objects version="1.0">
114 <object model="orm.toastersetting" pk="100">
115 <field name="name" type="CharField">CUSTOM_LAYERINDEX_SERVER</field>
116 <field name="value" type="CharField">https://layers.my_organization.org/layerindex/branch/master/layers/</field>
117 </object>
118 <django-objects>
119
120When you start Toaster for the first time, or
121if you delete the file ``toaster.sqlite`` and restart, the database will
122populate cleanly from this layer index server.
123
124Once the information has been updated, verify the new layer information
125is available by using the Toaster web interface. To do that, visit the
126"All compatible layers" page inside a Toaster project. The layers from
127your layer source should be listed there.
128
129If you change the information in your layer index server, refresh the
130Toaster database by running the following command:
131
132.. code-block:: shell
133
134 $ bitbake/lib/toaster/manage.py lsupdates
135
136
137If Toaster can reach the API URL, you should see a message telling you that
138Toaster is updating the layer source information.
139
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500140Releases
141========
142
143When you create a Toaster project using the web interface, you are asked
144to choose a "Release." In the context of Toaster, the term "Release"
145refers to a set of layers and a BitBake version the OpenEmbedded build
146system uses to build something. As shipped, Toaster is pre-configured
147with releases that correspond to Yocto Project release branches.
148However, you can modify, delete, and create new releases according to
149your needs. This section provides some background information on
150releases.
151
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500152Pre-Configured Releases
153-----------------------
154
155As shipped, Toaster is configured to use a specific set of releases. Of
156course, you can always configure Toaster to use any release. For
157example, you might want your project to build against a specific commit
158of any of the "out-of-the-box" releases. Or, you might want your project
159to build against different revisions of OpenEmbedded and BitBake.
160
161As shipped, Toaster is configured to work with the following releases:
162
163- *Yocto Project &DISTRO; "&DISTRO_NAME;" or OpenEmbedded "&DISTRO_NAME;":*
164 This release causes your Toaster projects to build against the head
165 of the &DISTRO_NAME_NO_CAP; branch at
Andrew Geissler09209ee2020-12-13 08:44:15 -0600166 :yocto_git:`/poky/log/?h=&DISTRO_NAME_NO_CAP;` or
167 :oe_git:`/openembedded-core/commit/?h=&DISTRO_NAME_NO_CAP;`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500168
169- *Yocto Project "Master" or OpenEmbedded "Master":* This release
170 causes your Toaster Projects to build against the head of the master
171 branch, which is where active development takes place, at
Andrew Geissler09209ee2020-12-13 08:44:15 -0600172 :yocto_git:`/poky/log/` or :oe_git:`/openembedded-core/log/`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500173
174- *Local Yocto Project or Local OpenEmbedded:* This release causes your
175 Toaster Projects to build against the head of the ``poky`` or
176 ``openembedded-core`` clone you have local to the machine running
177 Toaster.
178
179Configuring Toaster
180===================
181
182In order to use Toaster, you must configure the database with the
183default content. The following subsections describe various aspects of
184Toaster configuration.
185
186Configuring the Workflow
187------------------------
188
189The ``bldcontrol/management/commands/checksettings.py`` file controls
190workflow configuration. The following steps outline the process to
191initially populate this database.
192
1931. The default project settings are set from
194 ``orm/fixtures/settings.xml``.
195
1962. The default project distro and layers are added from
197 ``orm/fixtures/poky.xml`` if poky is installed. If poky is not
198 installed, they are added from ``orm/fixtures/oe-core.xml``.
199
2003. If the ``orm/fixtures/custom.xml`` file exists, then its values are
201 added.
202
2034. The layer index is then scanned and added to the database.
204
205Once these steps complete, Toaster is set up and ready to use.
206
207Customizing Pre-Set Data
208------------------------
209
210The pre-set data for Toaster is easily customizable. You can create the
211``orm/fixtures/custom.xml`` file to customize the values that go into to
212the database. Customization is additive, and can either extend or
213completely replace the existing values.
214
215You use the ``orm/fixtures/custom.xml`` file to change the default
216project settings for the machine, distro, file images, and layers. When
217creating a new project, you can use the file to define the offered
218alternate project release selections. For example, you can add one or
219more additional selections that present custom layer sets or distros,
220and any other local or proprietary content.
221
222Additionally, you can completely disable the content from the
223``oe-core.xml`` and ``poky.xml`` files by defining the section shown
224below in the ``settings.xml`` file. For example, this option is
225particularly useful if your custom configuration defines fewer releases
226or layers than the default fixture files.
227
228The following example sets "name" to "CUSTOM_XML_ONLY" and its value to
229"True".
230
231.. code-block:: xml
232
233 <object model="orm.toastersetting" pk="99">
234 <field type="CharField" name="name">CUSTOM_XML_ONLY</field>
235 <field type="CharField" name="value">True</field>
236 </object>
237
238Understanding Fixture File Format
239---------------------------------
240
241The following is an overview of the file format used by the
242``oe-core.xml``, ``poky.xml``, and ``custom.xml`` files.
243
244The following subsections describe each of the sections in the fixture
245files, and outline an example section of the XML code. you can use to
246help understand this information and create a local ``custom.xml`` file.
247
248Defining the Default Distro and Other Values
249~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
250
251This section defines the default distro value for new projects. By
252default, it reserves the first Toaster Setting record "1". The following
253demonstrates how to set the project default value for
254:term:`DISTRO`:
255
256.. code-block:: xml
257
258 <!-- Set the project default value for DISTRO -->
259 <object model="orm.toastersetting" pk="1">
260 <field type="CharField" name="name">DEFCONF_DISTRO</field>
261 <field type="CharField" name="value">poky</field>
262 </object>
263
264You can override
265other default project values by adding additional Toaster Setting
266sections such as any of the settings coming from the ``settings.xml``
267file. Also, you can add custom values that are included in the BitBake
268environment. The "pk" values must be unique. By convention, values that
269set default project values have a "DEFCONF" prefix.
270
271Defining BitBake Version
272~~~~~~~~~~~~~~~~~~~~~~~~
273
274The following defines which version of BitBake is used for the following
275release selection:
276
277.. code-block:: xml
278
279 <!-- Bitbake versions which correspond to the metadata release -->
280 <object model="orm.bitbakeversion" pk="1">
281 <field type="CharField" name="name">&DISTRO_NAME_NO_CAP;</field>
282 <field type="CharField" name="giturl">git://git.yoctoproject.org/poky</field>
283 <field type="CharField" name="branch">&DISTRO_NAME_NO_CAP;</field>
284 <field type="CharField" name="dirpath">bitbake</field>
285 </object>
286
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500287Defining Release
288~~~~~~~~~~~~~~~~
289
290The following defines the releases when you create a new project:
291
292.. code-block:: xml
293
294 <!-- Releases available -->
295 <object model="orm.release" pk="1">
296 <field type="CharField" name="name">&DISTRO_NAME_NO_CAP;</field>
297 <field type="CharField" name="description">Yocto Project &DISTRO; "&DISTRO_NAME;"</field>
298 <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">1</field>
299 <field type="CharField" name="branch_name">&DISTRO_NAME_NO_CAP;</field>
300 <field type="TextField" name="helptext">Toaster will run your builds using the tip of the <a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=&DISTRO_NAME_NO_CAP;">Yocto Project &DISTRO_NAME; branch</a>.</field>
301 </object>
302
303The "pk" value must match the above respective BitBake version record.
304
305Defining the Release Default Layer Names
306~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
307
308The following defines the default layers for each release:
309
310.. code-block:: xml
311
312 <!-- Default project layers for each release -->
313 <object model="orm.releasedefaultlayer" pk="1">
314 <field rel="ManyToOneRel" to="orm.release" name="release">1</field>
315 <field type="CharField" name="layer_name">openembedded-core</field>
316 </object>
317
318The 'pk' values in the example above should start at "1" and increment
319uniquely. You can use the same layer name in multiple releases.
320
321Defining Layer Definitions
322~~~~~~~~~~~~~~~~~~~~~~~~~~
323
324Layer definitions are the most complex. The following defines each of
325the layers, and then defines the exact layer version of the layer used
326for each respective release. You must have one ``orm.layer`` entry for
327each layer. Then, with each entry you need a set of
328``orm.layer_version`` entries that connects the layer with each release
329that includes the layer. In general all releases include the layer.
330
331.. code-block:: xml
332
333 <object model="orm.layer" pk="1">
334 <field type="CharField" name="name">openembedded-core</field>
335 <field type="CharField" name="layer_index_url"></field>
336 <field type="CharField" name="vcs_url">git://git.yoctoproject.org/poky</field>
337 <field type="CharField" name="vcs_web_url">http://git.yoctoproject.org/cgit/cgit.cgi/poky</field>
338 <field type="CharField" name="vcs_web_tree_base_url">http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/%path%?h=%branch%</field>
339 <field type="CharField" name="vcs_web_file_base_url">http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/%path%?h=%branch%</field>
340 </object>
341 <object model="orm.layer_version" pk="1">
342 <field rel="ManyToOneRel" to="orm.layer" name="layer">1</field>
343 <field type="IntegerField" name="layer_source">0</field>
344 <field rel="ManyToOneRel" to="orm.release" name="release">1</field>
345 <field type="CharField" name="branch">&DISTRO_NAME_NO_CAP;</field>
346 <field type="CharField" name="dirpath">meta</field>
347 </object> <object model="orm.layer_version" pk="2">
348 <field rel="ManyToOneRel" to="orm.layer" name="layer">1</field>
349 <field type="IntegerField" name="layer_source">0</field>
350 <field rel="ManyToOneRel" to="orm.release" name="release">2</field>
351 <field type="CharField" name="branch">HEAD</field>
352 <field type="CharField" name="commit">HEAD</field>
353 <field type="CharField" name="dirpath">meta</field>
354 </object>
355 <object model="orm.layer_version" pk="3">
356 <field rel="ManyToOneRel" to="orm.layer" name="layer">1</field>
357 <field type="IntegerField" name="layer_source">0</field>
358 <field rel="ManyToOneRel" to="orm.release" name="release">3</field>
359 <field type="CharField" name="branch">master</field>
360 <field type="CharField" name="dirpath">meta</field>
361 </object>
362
363The layer "pk" values above must be unique, and typically start at "1". The
364layer version "pk" values must also be unique across all layers, and typically
365start at "1".
366
367Remote Toaster Monitoring
368=========================
369
370Toaster has an API that allows remote management applications to
371directly query the state of the Toaster server and its builds in a
372machine-to-machine manner. This API uses the
373`REST <http://en.wikipedia.org/wiki/Representational_state_transfer>`__
374interface and the transfer of JSON files. For example, you might monitor
375a build inside a container through well supported known HTTP ports in
376order to easily access a Toaster server inside the container. In this
377example, when you use this direct JSON API, you avoid having web page
378parsing against the display the user sees.
379
380Checking Health
381---------------
382
383Before you use remote Toaster monitoring, you should do a health check.
384To do this, ping the Toaster server using the following call to see if
385it is still alive::
386
387 http://host:port/health
388
389Be sure to provide values for host and port. If the server is alive, you will
390get the response HTML:
391
392.. code-block:: html
393
394 <!DOCTYPE html>
395 <html lang="en">
396 <head><title>Toaster Health</title></head>
397 <body>Ok</body>
398 </html>
399
400Determining Status of Builds in Progress
401----------------------------------------
402
403Sometimes it is useful to determine the status of a build in progress.
404To get the status of pending builds, use the following call::
405
406 http://host:port/toastergui/api/building
407
408Be sure to provide values for host and port. The output is a JSON file that
409itemizes all builds in progress. This file includes the time in seconds since
410each respective build started as well as the progress of the cloning, parsing,
411and task execution. The following is sample output for a build in progress:
412
413.. code-block:: JSON
414
415 {"count": 1,
416 "building": [
417 {"machine": "beaglebone",
418 "seconds": "463.869",
419 "task": "927:2384",
420 "distro": "poky",
421 "clone": "1:1",
422 "id": 2,
423 "start": "2017-09-22T09:31:44.887Z",
424 "name": "20170922093200",
425 "parse": "818:818",
426 "project": "my_rocko",
427 "target": "core-image-minimal"
428 }]
429 }
430
431The JSON data for this query is returned in a
432single line. In the previous example the line has been artificially
433split for readability.
434
435Checking Status of Builds Completed
436-----------------------------------
437
438Once a build is completed, you get the status when you use the following
439call::
440
441 http://host:port/toastergui/api/builds
442
443Be sure to provide values for host and port. The output is a JSON file that
444itemizes all complete builds, and includes build summary information. The
445following is sample output for a completed build:
446
447.. code-block:: JSON
448
449 {"count": 1,
450 "builds": [
451 {"distro": "poky",
452 "errors": 0,
453 "machine": "beaglebone",
454 "project": "my_rocko",
455 "stop": "2017-09-22T09:26:36.017Z",
456 "target": "quilt-native",
457 "seconds": "78.193",
458 "outcome": "Succeeded",
459 "id": 1,
460 "start": "2017-09-22T09:25:17.824Z",
461 "warnings": 1,
462 "name": "20170922092618"
463 }]
464 }
465
466The JSON data for this query is returned in a single line. In the
467previous example the line has been artificially split for readability.
468
469Determining Status of a Specific Build
470--------------------------------------
471
472Sometimes it is useful to determine the status of a specific build. To
473get the status of a specific build, use the following call::
474
475 http://host:port/toastergui/api/build/ID
476
477Be sure to provide values for
478host, port, and ID. You can find the value for ID from the Builds
Andrew Geissler09209ee2020-12-13 08:44:15 -0600479Completed query. See the ":ref:`toaster-manual/reference:checking status of builds completed`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500480section for more information.
481
482The output is a JSON file that itemizes the specific build and includes
483build summary information. The following is sample output for a specific
484build:
485
486.. code-block:: JSON
487
488 {"build":
489 {"distro": "poky",
490 "errors": 0,
491 "machine": "beaglebone",
492 "project": "my_rocko",
493 "stop": "2017-09-22T09:26:36.017Z",
494 "target": "quilt-native",
495 "seconds": "78.193",
496 "outcome": "Succeeded",
497 "id": 1,
498 "start": "2017-09-22T09:25:17.824Z",
499 "warnings": 1,
500 "name": "20170922092618",
501 "cooker_log": "/opt/user/poky/build-toaster-2/tmp/log/cooker/beaglebone/build_20170922_022607.991.log"
502 }
503 }
504
505The JSON data for this query is returned in a single line. In the
506previous example the line has been artificially split for readability.
507
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500508Useful Commands
509===============
510
511In addition to the web user interface and the scripts that start and
512stop Toaster, command-line commands exist through the ``manage.py``
513management script. You can find general documentation on ``manage.py``
514at the
515`Django <https://docs.djangoproject.com/en/2.2/topics/settings/>`__
516site. However, several ``manage.py`` commands have been created that are
517specific to Toaster and are used to control configuration and back-end
518tasks. You can locate these commands in the
519:term:`Source Directory` (e.g. ``poky``) at
520``bitbake/lib/manage.py``. This section documents those commands.
521
522.. note::
523
524 - When using ``manage.py`` commands given a default configuration,
525 you must be sure that your working directory is set to the
526 :term:`Build Directory`. Using
527 ``manage.py`` commands from the Build Directory allows Toaster to
528 find the ``toaster.sqlite`` file, which is located in the Build
529 Directory.
530
531 - For non-default database configurations, it is possible that you
532 can use ``manage.py`` commands from a directory other than the
533 Build Directory. To do so, the ``toastermain/settings.py`` file
534 must be configured to point to the correct database backend.
535
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500536``buildslist``
537--------------
538
539The ``buildslist`` command lists all builds that Toaster has recorded.
540Access the command as follows:
541
542.. code-block:: shell
543
544 $ bitbake/lib/toaster/manage.py buildslist
545
546The command returns a list, which includes numeric
547identifications, of the builds that Toaster has recorded in the current
548database.
549
550You need to run the ``buildslist`` command first to identify existing
551builds in the database before using the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600552:ref:`toaster-manual/reference:\`\`builddelete\`\`` command. Here is an
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500553example that assumes default repository and build directory names:
554
555.. code-block:: shell
556
557 $ cd ~/poky/build
558 $ python ../bitbake/lib/toaster/manage.py buildslist
559
560If your Toaster database had only one build, the above
Andrew Geissler09209ee2020-12-13 08:44:15 -0600561:ref:`toaster-manual/reference:\`\`buildslist\`\``
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500562command would return something like the following::
563
564 1: qemux86 poky core-image-minimal
565
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500566``builddelete``
567---------------
568
569The ``builddelete`` command deletes data associated with a build. Access
570the command as follows:
571
572.. code-block::
573
574 $ bitbake/lib/toaster/manage.py builddelete build_id
575
576The command deletes all the build data for the specified
577build_id. This command is useful for removing old and unused data from
578the database.
579
580Prior to running the ``builddelete`` command, you need to get the ID
581associated with builds by using the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600582:ref:`toaster-manual/reference:\`\`buildslist\`\`` command.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500583
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500584``perf``
585--------
586
587The ``perf`` command measures Toaster performance. Access the command as
588follows:
589
590.. code-block:: shell
591
592 $ bitbake/lib/toaster/manage.py perf
593
594The command is a sanity check that returns page loading times in order to
595identify performance problems.
596
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500597``checksettings``
598-----------------
599
600The ``checksettings`` command verifies existing Toaster settings. Access
601the command as follows:
602
603.. code-block:: shell
604
605 $ bitbake/lib/toaster/manage.py checksettings
606
607Toaster uses settings that are based on the database to configure the
608building tasks. The ``checksettings`` command verifies that the database
609settings are valid in the sense that they have the minimal information
610needed to start a build.
611
612In order for the ``checksettings`` command to work, the database must be
613correctly set up and not have existing data. To be sure the database is
614ready, you can run the following:
615
616.. code-block:: shell
617
618 $ bitbake/lib/toaster/manage.py syncdb
619 $ bitbake/lib/toaster/manage.py migrate orm
620 $ bitbake/lib/toaster/manage.py migrate bldcontrol
621
622After running these commands, you can run the ``checksettings`` command.
623
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500624``runbuilds``
625-------------
626
627The ``runbuilds`` command launches scheduled builds. Access the command
628as follows:
629
630.. code-block:: shell
631
632 $ bitbake/lib/toaster/manage.py runbuilds
633
634The ``runbuilds`` command checks if scheduled builds exist in the database
635and then launches them per schedule. The command returns after the builds
636start but before they complete. The Toaster Logging Interface records and
637updates the database when the builds complete.