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