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