diff options
author | Tim Orling <timothy.t.orling@linux.intel.com> | 2020-09-16 13:13:37 -0700 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2020-09-17 10:09:35 +0100 |
commit | b199ff072e7d59255df4b414947f43a522c166e2 (patch) | |
tree | 80298d44138bf67fce3d00749f0dbfe136f813e6 /documentation/toaster-manual/toaster-manual-reference.rst | |
parent | f8b4bbda0316d2f1b276cb2ed2cf25422c418ac1 (diff) | |
download | poky-b199ff072e7d59255df4b414947f43a522c166e2.tar.gz |
sphinx: toaster-manual: fix vars, links, code blocks
Also update Django links to 2.2 LTS release (from 1.11)
Replace most references to 'rocko' with variable
(From yocto-docs rev: ddf1e119db93fc3f8b141a04f6d0009f933b1006)
Signed-off-by: Tim Orling <timothy.t.orling@linux.intel.com>
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/toaster-manual/toaster-manual-reference.rst')
-rw-r--r-- | documentation/toaster-manual/toaster-manual-reference.rst | 423 |
1 files changed, 284 insertions, 139 deletions
diff --git a/documentation/toaster-manual/toaster-manual-reference.rst b/documentation/toaster-manual/toaster-manual-reference.rst index a628c78cc2..e95536e052 100644 --- a/documentation/toaster-manual/toaster-manual-reference.rst +++ b/documentation/toaster-manual/toaster-manual-reference.rst | |||
@@ -67,11 +67,10 @@ familiar with where they reside. You will need that information when you | |||
67 | set up the code for the web application that "hooks" into your set of | 67 | set up the code for the web application that "hooks" into your set of |
68 | layers. | 68 | layers. |
69 | 69 | ||
70 | For general information on layers, see the "`The Yocto Project Layer | 70 | For general information on layers, see the |
71 | Model <&YOCTO_DOCS_OM_URL;#the-yocto-project-layer-model>`__" section in | 71 | ":ref:`overview-manual/overview-manual-yp-intro:the yocto project layer model`" |
72 | the Yocto Project Overview and Concepts Manual. For information on how | 72 | section in the Yocto Project Overview and Concepts Manual. For information on how |
73 | to create layers, see the "`Understanding and Creating | 73 | to create layers, see the ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`" |
74 | Layers <&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers>`__" | ||
75 | section in the Yocto Project Development Tasks Manual. | 74 | section in the Yocto Project Development Tasks Manual. |
76 | 75 | ||
77 | .. _configuring-toaster-to-hook-into-your-layer-source: | 76 | .. _configuring-toaster-to-hook-into-your-layer-source: |
@@ -98,7 +97,9 @@ Use the Administration Interface | |||
98 | Access the administration interface through a browser by entering the | 97 | Access the administration interface through a browser by entering the |
99 | URL of your Toaster instance and adding "``/admin``" to the end of the | 98 | URL of your Toaster instance and adding "``/admin``" to the end of the |
100 | URL. As an example, if you are running Toaster locally, use the | 99 | URL. As an example, if you are running Toaster locally, use the |
101 | following URL: http://127.0.0.1:8000/admin | 100 | following URL:: |
101 | |||
102 | http://127.0.0.1:8000/admin | ||
102 | 103 | ||
103 | The administration interface has a "Layer sources" section that includes | 104 | The administration interface has a "Layer sources" section that includes |
104 | an "Add layer source" button. Click that button and provide the required | 105 | an "Add layer source" button. Click that button and provide the required |
@@ -110,12 +111,19 @@ Use the Fixture Feature | |||
110 | The Django fixture feature overrides the default layer server when you | 111 | The Django fixture feature overrides the default layer server when you |
111 | use it to specify a custom URL. To use the fixture feature, create (or | 112 | use it to specify a custom URL. To use the fixture feature, create (or |
112 | edit) the file ``bitbake/lib/toaster.orm/fixtures/custom.xml``, and then | 113 | edit) the file ``bitbake/lib/toaster.orm/fixtures/custom.xml``, and then |
113 | set the following Toaster setting to your custom URL: <?xml | 114 | set the following Toaster setting to your custom URL: |
114 | version="1.0" ?> <django-objects version="1.0"> <object | 115 | |
115 | model="orm.toastersetting" pk="100"> <field name="name" | 116 | .. code-block:: xml |
116 | type="CharField">CUSTOM_LAYERINDEX_SERVER</field> <field name="value" | 117 | |
117 | type="CharField">https://layers.my_organization.org/layerindex/branch/master/layers/</field> | 118 | <?xml version="1.0" ?> |
118 | </object> <django-objects> When you start Toaster for the first time, or | 119 | <django-objects version="1.0"> |
120 | <object model="orm.toastersetting" pk="100"> | ||
121 | <field name="name" type="CharField">CUSTOM_LAYERINDEX_SERVER</field> | ||
122 | <field name="value" type="CharField">https://layers.my_organization.org/layerindex/branch/master/layers/</field> | ||
123 | </object> | ||
124 | <django-objects> | ||
125 | |||
126 | When you start Toaster for the first time, or | ||
119 | if you delete the file ``toaster.sqlite`` and restart, the database will | 127 | if you delete the file ``toaster.sqlite`` and restart, the database will |
120 | populate cleanly from this layer index server. | 128 | populate cleanly from this layer index server. |
121 | 129 | ||
@@ -125,10 +133,15 @@ is available by using the Toaster web interface. To do that, visit the | |||
125 | your layer source should be listed there. | 133 | your layer source should be listed there. |
126 | 134 | ||
127 | If you change the information in your layer index server, refresh the | 135 | If you change the information in your layer index server, refresh the |
128 | Toaster database by running the following command: $ | 136 | Toaster database by running the following command: |
129 | bitbake/lib/toaster/manage.py lsupdates If Toaster can reach the API | 137 | |
130 | URL, you should see a message telling you that Toaster is updating the | 138 | .. code-block:: shell |
131 | layer source information. | 139 | |
140 | $ bitbake/lib/toaster/manage.py lsupdates | ||
141 | |||
142 | |||
143 | If Toaster can reach the API URL, you should see a message telling you that | ||
144 | Toaster is updating the layer source information. | ||
132 | 145 | ||
133 | .. _toaster-releases: | 146 | .. _toaster-releases: |
134 | 147 | ||
@@ -157,11 +170,11 @@ to build against different revisions of OpenEmbedded and BitBake. | |||
157 | 170 | ||
158 | As shipped, Toaster is configured to work with the following releases: | 171 | As shipped, Toaster is configured to work with the following releases: |
159 | 172 | ||
160 | - *Yocto Project DISTRO "DISTRO_NAME" or OpenEmbedded "DISTRO_NAME":* | 173 | - *Yocto Project &DISTRO; "&DISTRO_NAME;" or OpenEmbedded "&DISTRO_NAME;":* |
161 | This release causes your Toaster projects to build against the head | 174 | This release causes your Toaster projects to build against the head |
162 | of the DISTRO_NAME_NO_CAP branch at | 175 | of the &DISTRO_NAME_NO_CAP; branch at |
163 | https://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=rocko or | 176 | https://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=&DISTRO_NAME_NO_CAP; or |
164 | http://git.openembedded.org/openembedded-core/commit/?h=rocko. | 177 | http://git.openembedded.org/openembedded-core/commit/?h=&DISTRO_NAME_NO_CAP;. |
165 | 178 | ||
166 | - *Yocto Project "Master" or OpenEmbedded "Master":* This release | 179 | - *Yocto Project "Master" or OpenEmbedded "Master":* This release |
167 | causes your Toaster Projects to build against the head of the master | 180 | causes your Toaster Projects to build against the head of the master |
@@ -224,9 +237,14 @@ particularly useful if your custom configuration defines fewer releases | |||
224 | or layers than the default fixture files. | 237 | or layers than the default fixture files. |
225 | 238 | ||
226 | The following example sets "name" to "CUSTOM_XML_ONLY" and its value to | 239 | The following example sets "name" to "CUSTOM_XML_ONLY" and its value to |
227 | "True". <object model="orm.toastersetting" pk="99"> <field | 240 | "True". |
228 | type="CharField" name="name">CUSTOM_XML_ONLY</field> <field | 241 | |
229 | type="CharField" name="value">True</field> </object> | 242 | .. code-block:: xml |
243 | |||
244 | <object model="orm.toastersetting" pk="99"> | ||
245 | <field type="CharField" name="name">CUSTOM_XML_ONLY</field> | ||
246 | <field type="CharField" name="value">True</field> | ||
247 | </object> | ||
230 | 248 | ||
231 | Understanding Fixture File Format | 249 | Understanding Fixture File Format |
232 | --------------------------------- | 250 | --------------------------------- |
@@ -244,10 +262,17 @@ Defining the Default Distro and Other Values | |||
244 | This section defines the default distro value for new projects. By | 262 | This section defines the default distro value for new projects. By |
245 | default, it reserves the first Toaster Setting record "1". The following | 263 | default, it reserves the first Toaster Setting record "1". The following |
246 | demonstrates how to set the project default value for | 264 | demonstrates how to set the project default value for |
247 | :term:`DISTRO`: <!-- Set the project | 265 | :term:`DISTRO`: |
248 | default value for DISTRO --> <object model="orm.toastersetting" pk="1"> | 266 | |
249 | <field type="CharField" name="name">DEFCONF_DISTRO</field> <field | 267 | .. code-block:: xml |
250 | type="CharField" name="value">poky</field> </object> You can override | 268 | |
269 | <!-- Set the project default value for DISTRO --> | ||
270 | <object model="orm.toastersetting" pk="1"> | ||
271 | <field type="CharField" name="name">DEFCONF_DISTRO</field> | ||
272 | <field type="CharField" name="value">poky</field> | ||
273 | </object> | ||
274 | |||
275 | You can override | ||
251 | other default project values by adding additional Toaster Setting | 276 | other default project values by adding additional Toaster Setting |
252 | sections such as any of the settings coming from the ``settings.xml`` | 277 | sections such as any of the settings coming from the ``settings.xml`` |
253 | file. Also, you can add custom values that are included in the BitBake | 278 | file. Also, you can add custom values that are included in the BitBake |
@@ -258,40 +283,53 @@ Defining BitBake Version | |||
258 | ~~~~~~~~~~~~~~~~~~~~~~~~ | 283 | ~~~~~~~~~~~~~~~~~~~~~~~~ |
259 | 284 | ||
260 | The following defines which version of BitBake is used for the following | 285 | The following defines which version of BitBake is used for the following |
261 | release selection: <!-- Bitbake versions which correspond to the | 286 | release selection: |
262 | metadata release --> <object model="orm.bitbakeversion" pk="1"> <field | 287 | |
263 | type="CharField" name="name">rocko</field> <field type="CharField" | 288 | .. code-block:: xml |
264 | name="giturl">git://git.yoctoproject.org/poky</field> <field | 289 | |
265 | type="CharField" name="branch">rocko</field> <field type="CharField" | 290 | <!-- Bitbake versions which correspond to the metadata release --> |
266 | name="dirpath">bitbake</field> </object> | 291 | <object model="orm.bitbakeversion" pk="1"> |
292 | <field type="CharField" name="name">&DISTRO_NAME_NO_CAP;</field> | ||
293 | <field type="CharField" name="giturl">git://git.yoctoproject.org/poky</field> | ||
294 | <field type="CharField" name="branch">&DISTRO_NAME_NO_CAP;</field> | ||
295 | <field type="CharField" name="dirpath">bitbake</field> | ||
296 | </object> | ||
267 | 297 | ||
268 | .. _defining-releases: | 298 | .. _defining-releases: |
269 | 299 | ||
270 | Defining Release | 300 | Defining Release |
271 | ~~~~~~~~~~~~~~~~ | 301 | ~~~~~~~~~~~~~~~~ |
272 | 302 | ||
273 | The following defines the releases when you create a new project. <!-- | 303 | The following defines the releases when you create a new project: |
274 | Releases available --> <object model="orm.release" pk="1"> <field | 304 | |
275 | type="CharField" name="name">rocko</field> <field type="CharField" | 305 | .. code-block:: xml |
276 | name="description">Yocto Project 2.4 "Rocko"</field> <field | 306 | |
277 | rel="ManyToOneRel" to="orm.bitbakeversion" | 307 | <!-- Releases available --> |
278 | name="bitbake_version">1</field> <field type="CharField" | 308 | <object model="orm.release" pk="1"> |
279 | name="branch_name">rocko</field> <field type="TextField" | 309 | <field type="CharField" name="name">&DISTRO_NAME_NO_CAP;</field> |
280 | name="helptext">Toaster will run your builds using the tip of the <a | 310 | <field type="CharField" name="description">Yocto Project &DISTRO; "&DISTRO_NAME;"</field> |
281 | href="http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=rocko">Yocto | 311 | <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">1</field> |
282 | Project Rocko branch</a>.</field> </object> The "pk" value must match | 312 | <field type="CharField" name="branch_name">&DISTRO_NAME_NO_CAP;</field> |
283 | the above respective BitBake version record. | 313 | <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> |
314 | </object> | ||
315 | |||
316 | The "pk" value must match the above respective BitBake version record. | ||
284 | 317 | ||
285 | Defining the Release Default Layer Names | 318 | Defining the Release Default Layer Names |
286 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 319 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
287 | 320 | ||
288 | The following defines the default layers for each release: <!-- Default | 321 | The following defines the default layers for each release: |
289 | project layers for each release --> <object | 322 | |
290 | model="orm.releasedefaultlayer" pk="1"> <field rel="ManyToOneRel" | 323 | .. code-block:: xml |
291 | to="orm.release" name="release">1</field> <field type="CharField" | 324 | |
292 | name="layer_name">openembedded-core</field> </object> The 'pk' values in | 325 | <!-- Default project layers for each release --> |
293 | the example above should start at "1" and increment uniquely. You can | 326 | <object model="orm.releasedefaultlayer" pk="1"> |
294 | use the same layer name in multiple releases. | 327 | <field rel="ManyToOneRel" to="orm.release" name="release">1</field> |
328 | <field type="CharField" name="layer_name">openembedded-core</field> | ||
329 | </object> | ||
330 | |||
331 | The 'pk' values in the example above should start at "1" and increment | ||
332 | uniquely. You can use the same layer name in multiple releases. | ||
295 | 333 | ||
296 | Defining Layer Definitions | 334 | Defining Layer Definitions |
297 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ | 335 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ |
@@ -302,35 +340,42 @@ for each respective release. You must have one ``orm.layer`` entry for | |||
302 | each layer. Then, with each entry you need a set of | 340 | each layer. Then, with each entry you need a set of |
303 | ``orm.layer_version`` entries that connects the layer with each release | 341 | ``orm.layer_version`` entries that connects the layer with each release |
304 | that includes the layer. In general all releases include the layer. | 342 | that includes the layer. In general all releases include the layer. |
305 | <object model="orm.layer" pk="1"> <field type="CharField" | 343 | |
306 | name="name">openembedded-core</field> <field type="CharField" | 344 | .. code-block:: xml |
307 | name="layer_index_url"></field> <field type="CharField" | 345 | |
308 | name="vcs_url">git://git.yoctoproject.org/poky</field> <field | 346 | <object model="orm.layer" pk="1"> |
309 | type="CharField" | 347 | <field type="CharField" name="name">openembedded-core</field> |
310 | name="vcs_web_url">http://git.yoctoproject.org/cgit/cgit.cgi/poky</field> | 348 | <field type="CharField" name="layer_index_url"></field> |
311 | <field type="CharField" | 349 | <field type="CharField" name="vcs_url">git://git.yoctoproject.org/poky</field> |
312 | name="vcs_web_tree_base_url">http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/%path%?h=%branch%</field> | 350 | <field type="CharField" name="vcs_web_url">http://git.yoctoproject.org/cgit/cgit.cgi/poky</field> |
313 | <field type="CharField" | 351 | <field type="CharField" name="vcs_web_tree_base_url">http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/%path%?h=%branch%</field> |
314 | name="vcs_web_file_base_url">http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/%path%?h=%branch%</field> | 352 | <field type="CharField" name="vcs_web_file_base_url">http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/%path%?h=%branch%</field> |
315 | </object> <object model="orm.layer_version" pk="1"> <field | 353 | </object> |
316 | rel="ManyToOneRel" to="orm.layer" name="layer">1</field> <field | 354 | <object model="orm.layer_version" pk="1"> |
317 | type="IntegerField" name="layer_source">0</field> <field | 355 | <field rel="ManyToOneRel" to="orm.layer" name="layer">1</field> |
318 | rel="ManyToOneRel" to="orm.release" name="release">1</field> <field | 356 | <field type="IntegerField" name="layer_source">0</field> |
319 | type="CharField" name="branch">rocko</field> <field type="CharField" | 357 | <field rel="ManyToOneRel" to="orm.release" name="release">1</field> |
320 | name="dirpath">meta</field> </object> <object model="orm.layer_version" | 358 | <field type="CharField" name="branch">&DISTRO_NAME_NO_CAP;</field> |
321 | pk="2"> <field rel="ManyToOneRel" to="orm.layer" name="layer">1</field> | 359 | <field type="CharField" name="dirpath">meta</field> |
322 | <field type="IntegerField" name="layer_source">0</field> <field | 360 | </object> <object model="orm.layer_version" pk="2"> |
323 | rel="ManyToOneRel" to="orm.release" name="release">2</field> <field | 361 | <field rel="ManyToOneRel" to="orm.layer" name="layer">1</field> |
324 | type="CharField" name="branch">HEAD</field> <field type="CharField" | 362 | <field type="IntegerField" name="layer_source">0</field> |
325 | name="commit">HEAD</field> <field type="CharField" | 363 | <field rel="ManyToOneRel" to="orm.release" name="release">2</field> |
326 | name="dirpath">meta</field> </object> <object model="orm.layer_version" | 364 | <field type="CharField" name="branch">HEAD</field> |
327 | pk="3"> <field rel="ManyToOneRel" to="orm.layer" name="layer">1</field> | 365 | <field type="CharField" name="commit">HEAD</field> |
328 | <field type="IntegerField" name="layer_source">0</field> <field | 366 | <field type="CharField" name="dirpath">meta</field> |
329 | rel="ManyToOneRel" to="orm.release" name="release">3</field> <field | 367 | </object> |
330 | type="CharField" name="branch">master</field> <field type="CharField" | 368 | <object model="orm.layer_version" pk="3"> |
331 | name="dirpath">meta</field> </object> The layer "pk" values above must | 369 | <field rel="ManyToOneRel" to="orm.layer" name="layer">1</field> |
332 | be unique, and typically start at "1". The layer version "pk" values | 370 | <field type="IntegerField" name="layer_source">0</field> |
333 | must also be unique across all layers, and typically start at "1". | 371 | <field rel="ManyToOneRel" to="orm.release" name="release">3</field> |
372 | <field type="CharField" name="branch">master</field> | ||
373 | <field type="CharField" name="dirpath">meta</field> | ||
374 | </object> | ||
375 | |||
376 | The layer "pk" values above must be unique, and typically start at "1". The | ||
377 | layer version "pk" values must also be unique across all layers, and typically | ||
378 | start at "1". | ||
334 | 379 | ||
335 | Remote Toaster Monitoring | 380 | Remote Toaster Monitoring |
336 | ========================= | 381 | ========================= |
@@ -350,26 +395,53 @@ Checking Health | |||
350 | 395 | ||
351 | Before you use remote Toaster monitoring, you should do a health check. | 396 | Before you use remote Toaster monitoring, you should do a health check. |
352 | To do this, ping the Toaster server using the following call to see if | 397 | To do this, ping the Toaster server using the following call to see if |
353 | it is still alive: http://host:port/health Be sure to provide values for | 398 | it is still alive:: |
354 | host and port. If the server is alive, you will get the response HTML: | 399 | |
355 | <!DOCTYPE html> <html lang="en"> <head><title>Toaster | 400 | http://host:port/health |
356 | Health</title></head> <body>Ok</body> </html> | 401 | |
402 | Be sure to provide values for host and port. If the server is alive, you will | ||
403 | get the response HTML: | ||
404 | |||
405 | .. code-block:: html | ||
406 | |||
407 | <!DOCTYPE html> | ||
408 | <html lang="en"> | ||
409 | <head><title>Toaster Health</title></head> | ||
410 | <body>Ok</body> | ||
411 | </html> | ||
357 | 412 | ||
358 | Determining Status of Builds in Progress | 413 | Determining Status of Builds in Progress |
359 | ---------------------------------------- | 414 | ---------------------------------------- |
360 | 415 | ||
361 | Sometimes it is useful to determine the status of a build in progress. | 416 | Sometimes it is useful to determine the status of a build in progress. |
362 | To get the status of pending builds, use the following call: | 417 | To get the status of pending builds, use the following call:: |
363 | http://host:port/toastergui/api/building Be sure to provide values for | 418 | |
364 | host and port. The output is a JSON file that itemizes all builds in | 419 | http://host:port/toastergui/api/building |
365 | progress. This file includes the time in seconds since each respective | 420 | |
366 | build started as well as the progress of the cloning, parsing, and task | 421 | Be sure to provide values for host and port. The output is a JSON file that |
367 | execution. The following is sample output for a build in progress: | 422 | itemizes all builds in progress. This file includes the time in seconds since |
368 | {"count": 1, "building": [ {"machine": "beaglebone", "seconds": | 423 | each respective build started as well as the progress of the cloning, parsing, |
369 | "463.869", "task": "927:2384", "distro": "poky", "clone": "1:1", "id": | 424 | and task execution. The following is sample output for a build in progress: |
370 | 2, "start": "2017-09-22T09:31:44.887Z", "name": "20170922093200", | 425 | |
371 | "parse": "818:818", "project": "my_rocko", "target": | 426 | .. code-block:: JSON |
372 | "core-image-minimal" }] } The JSON data for this query is returned in a | 427 | |
428 | {"count": 1, | ||
429 | "building": [ | ||
430 | {"machine": "beaglebone", | ||
431 | "seconds": "463.869", | ||
432 | "task": "927:2384", | ||
433 | "distro": "poky", | ||
434 | "clone": "1:1", | ||
435 | "id": 2, | ||
436 | "start": "2017-09-22T09:31:44.887Z", | ||
437 | "name": "20170922093200", | ||
438 | "parse": "818:818", | ||
439 | "project": "my_rocko", | ||
440 | "target": "core-image-minimal" | ||
441 | }] | ||
442 | } | ||
443 | |||
444 | The JSON data for this query is returned in a | ||
373 | single line. In the previous example the line has been artificially | 445 | single line. In the previous example the line has been artificially |
374 | split for readability. | 446 | split for readability. |
375 | 447 | ||
@@ -377,14 +449,33 @@ Checking Status of Builds Completed | |||
377 | ----------------------------------- | 449 | ----------------------------------- |
378 | 450 | ||
379 | Once a build is completed, you get the status when you use the following | 451 | Once a build is completed, you get the status when you use the following |
380 | call: http://host:port/toastergui/api/builds Be sure to provide values | 452 | call:: |
381 | for host and port. The output is a JSON file that itemizes all complete | 453 | |
382 | builds, and includes build summary information. The following is sample | 454 | http://host:port/toastergui/api/builds |
383 | output for a completed build: {"count": 1, "builds": [ {"distro": | 455 | |
384 | "poky", "errors": 0, "machine": "beaglebone", "project": "my_rocko", | 456 | Be sure to provide values for host and port. The output is a JSON file that |
385 | "stop": "2017-09-22T09:26:36.017Z", "target": "quilt-native", "seconds": | 457 | itemizes all complete builds, and includes build summary information. The |
386 | "78.193", "outcome": "Succeeded", "id": 1, "start": | 458 | following is sample output for a completed build: |
387 | "2017-09-22T09:25:17.824Z", "warnings": 1, "name": "20170922092618" }] } | 459 | |
460 | .. code-block:: JSON | ||
461 | |||
462 | {"count": 1, | ||
463 | "builds": [ | ||
464 | {"distro": "poky", | ||
465 | "errors": 0, | ||
466 | "machine": "beaglebone", | ||
467 | "project": "my_rocko", | ||
468 | "stop": "2017-09-22T09:26:36.017Z", | ||
469 | "target": "quilt-native", | ||
470 | "seconds": "78.193", | ||
471 | "outcome": "Succeeded", | ||
472 | "id": 1, | ||
473 | "start": "2017-09-22T09:25:17.824Z", | ||
474 | "warnings": 1, | ||
475 | "name": "20170922092618" | ||
476 | }] | ||
477 | } | ||
478 | |||
388 | The JSON data for this query is returned in a single line. In the | 479 | The JSON data for this query is returned in a single line. In the |
389 | previous example the line has been artificially split for readability. | 480 | previous example the line has been artificially split for readability. |
390 | 481 | ||
@@ -392,22 +483,39 @@ Determining Status of a Specific Build | |||
392 | -------------------------------------- | 483 | -------------------------------------- |
393 | 484 | ||
394 | Sometimes it is useful to determine the status of a specific build. To | 485 | Sometimes it is useful to determine the status of a specific build. To |
395 | get the status of a specific build, use the following call: | 486 | get the status of a specific build, use the following call:: |
396 | http://host:port/toastergui/api/build/ID Be sure to provide values for | 487 | |
488 | http://host:port/toastergui/api/build/ID | ||
489 | |||
490 | Be sure to provide values for | ||
397 | host, port, and ID. You can find the value for ID from the Builds | 491 | host, port, and ID. You can find the value for ID from the Builds |
398 | Completed query. See the "`Checking Status of Builds | 492 | Completed query. See the ":ref:`toaster-manual/toaster-manual-reference:checking status of builds completed`" |
399 | Completed <#checking-status-of-builds-completed>`__" section for more | 493 | section for more information. |
400 | information. | ||
401 | 494 | ||
402 | The output is a JSON file that itemizes the specific build and includes | 495 | The output is a JSON file that itemizes the specific build and includes |
403 | build summary information. The following is sample output for a specific | 496 | build summary information. The following is sample output for a specific |
404 | build: {"build": {"distro": "poky", "errors": 0, "machine": | 497 | build: |
405 | "beaglebone", "project": "my_rocko", "stop": "2017-09-22T09:26:36.017Z", | 498 | |
406 | "target": "quilt-native", "seconds": "78.193", "outcome": "Succeeded", | 499 | .. code-block:: JSON |
407 | "id": 1, "start": "2017-09-22T09:25:17.824Z", "warnings": 1, "name": | 500 | |
408 | "20170922092618", "cooker_log": | 501 | {"build": |
409 | "/opt/user/poky/build-toaster-2/tmp/log/cooker/beaglebone/build_20170922_022607.991.log" | 502 | {"distro": "poky", |
410 | } } The JSON data for this query is returned in a single line. In the | 503 | "errors": 0, |
504 | "machine": "beaglebone", | ||
505 | "project": "my_rocko", | ||
506 | "stop": "2017-09-22T09:26:36.017Z", | ||
507 | "target": "quilt-native", | ||
508 | "seconds": "78.193", | ||
509 | "outcome": "Succeeded", | ||
510 | "id": 1, | ||
511 | "start": "2017-09-22T09:25:17.824Z", | ||
512 | "warnings": 1, | ||
513 | "name": "20170922092618", | ||
514 | "cooker_log": "/opt/user/poky/build-toaster-2/tmp/log/cooker/beaglebone/build_20170922_022607.991.log" | ||
515 | } | ||
516 | } | ||
517 | |||
518 | The JSON data for this query is returned in a single line. In the | ||
411 | previous example the line has been artificially split for readability. | 519 | previous example the line has been artificially split for readability. |
412 | 520 | ||
413 | .. _toaster-useful-commands: | 521 | .. _toaster-useful-commands: |
@@ -419,7 +527,7 @@ In addition to the web user interface and the scripts that start and | |||
419 | stop Toaster, command-line commands exist through the ``manage.py`` | 527 | stop Toaster, command-line commands exist through the ``manage.py`` |
420 | management script. You can find general documentation on ``manage.py`` | 528 | management script. You can find general documentation on ``manage.py`` |
421 | at the | 529 | at the |
422 | `Django <https://docs.djangoproject.com/en/1.7/topics/settings/>`__ | 530 | `Django <https://docs.djangoproject.com/en/2.2/topics/settings/>`__ |
423 | site. However, several ``manage.py`` commands have been created that are | 531 | site. However, several ``manage.py`` commands have been created that are |
424 | specific to Toaster and are used to control configuration and back-end | 532 | specific to Toaster and are used to control configuration and back-end |
425 | tasks. You can locate these commands in the | 533 | tasks. You can locate these commands in the |
@@ -446,19 +554,31 @@ tasks. You can locate these commands in the | |||
446 | -------------- | 554 | -------------- |
447 | 555 | ||
448 | The ``buildslist`` command lists all builds that Toaster has recorded. | 556 | The ``buildslist`` command lists all builds that Toaster has recorded. |
449 | Access the command as follows: $ bitbake/lib/toaster/manage.py | 557 | Access the command as follows: |
450 | buildslist The command returns a list, which includes numeric | 558 | |
559 | .. code-block:: shell | ||
560 | |||
561 | $ bitbake/lib/toaster/manage.py buildslist | ||
562 | |||
563 | The command returns a list, which includes numeric | ||
451 | identifications, of the builds that Toaster has recorded in the current | 564 | identifications, of the builds that Toaster has recorded in the current |
452 | database. | 565 | database. |
453 | 566 | ||
454 | You need to run the ``buildslist`` command first to identify existing | 567 | You need to run the ``buildslist`` command first to identify existing |
455 | builds in the database before using the | 568 | builds in the database before using the |
456 | ```builddelete`` <#toaster-command-builddelete>`__ command. Here is an | 569 | :ref:`toaster-manual/toaster-manual-reference:\`\`builddelete\`\`` command. Here is an |
457 | example that assumes default repository and build directory names: $ cd | 570 | example that assumes default repository and build directory names: |
458 | ~/poky/build $ python ../bitbake/lib/toaster/manage.py buildslist If | 571 | |
459 | your Toaster database had only one build, the above ``buildslist`` | 572 | .. code-block:: shell |
460 | command would return something like the following: 1: qemux86 poky | 573 | |
461 | core-image-minimal | 574 | $ cd ~/poky/build |
575 | $ python ../bitbake/lib/toaster/manage.py buildslist | ||
576 | |||
577 | If your Toaster database had only one build, the above | ||
578 | :ref:`toaster-manual/toaster-manual-reference:\`\`buildslist\`\`` | ||
579 | command would return something like the following:: | ||
580 | |||
581 | 1: qemux86 poky core-image-minimal | ||
462 | 582 | ||
463 | .. _toaster-command-builddelete: | 583 | .. _toaster-command-builddelete: |
464 | 584 | ||
@@ -466,14 +586,19 @@ core-image-minimal | |||
466 | --------------- | 586 | --------------- |
467 | 587 | ||
468 | The ``builddelete`` command deletes data associated with a build. Access | 588 | The ``builddelete`` command deletes data associated with a build. Access |
469 | the command as follows: $ bitbake/lib/toaster/manage.py builddelete | 589 | the command as follows: |
470 | build_id The command deletes all the build data for the specified | 590 | |
591 | .. code-block:: | ||
592 | |||
593 | $ bitbake/lib/toaster/manage.py builddelete build_id | ||
594 | |||
595 | The command deletes all the build data for the specified | ||
471 | build_id. This command is useful for removing old and unused data from | 596 | build_id. This command is useful for removing old and unused data from |
472 | the database. | 597 | the database. |
473 | 598 | ||
474 | Prior to running the ``builddelete`` command, you need to get the ID | 599 | Prior to running the ``builddelete`` command, you need to get the ID |
475 | associated with builds by using the | 600 | associated with builds by using the |
476 | ```buildslist`` <#toaster-command-buildslist>`__ command. | 601 | :ref:`toaster-manual/toaster-manual-reference:\`\`buildslist\`\`` command. |
477 | 602 | ||
478 | .. _toaster-command-perf: | 603 | .. _toaster-command-perf: |
479 | 604 | ||
@@ -481,9 +606,14 @@ associated with builds by using the | |||
481 | -------- | 606 | -------- |
482 | 607 | ||
483 | The ``perf`` command measures Toaster performance. Access the command as | 608 | The ``perf`` command measures Toaster performance. Access the command as |
484 | follows: $ bitbake/lib/toaster/manage.py perf The command is a sanity | 609 | follows: |
485 | check that returns page loading times in order to identify performance | 610 | |
486 | problems. | 611 | .. code-block:: shell |
612 | |||
613 | $ bitbake/lib/toaster/manage.py perf | ||
614 | |||
615 | The command is a sanity check that returns page loading times in order to | ||
616 | identify performance problems. | ||
487 | 617 | ||
488 | .. _toaster-command-checksettings: | 618 | .. _toaster-command-checksettings: |
489 | 619 | ||
@@ -491,7 +621,12 @@ problems. | |||
491 | ----------------- | 621 | ----------------- |
492 | 622 | ||
493 | The ``checksettings`` command verifies existing Toaster settings. Access | 623 | The ``checksettings`` command verifies existing Toaster settings. Access |
494 | the command as follows: $ bitbake/lib/toaster/manage.py checksettings | 624 | the command as follows: |
625 | |||
626 | .. code-block:: shell | ||
627 | |||
628 | $ bitbake/lib/toaster/manage.py checksettings | ||
629 | |||
495 | Toaster uses settings that are based on the database to configure the | 630 | Toaster uses settings that are based on the database to configure the |
496 | building tasks. The ``checksettings`` command verifies that the database | 631 | building tasks. The ``checksettings`` command verifies that the database |
497 | settings are valid in the sense that they have the minimal information | 632 | settings are valid in the sense that they have the minimal information |
@@ -499,10 +634,15 @@ needed to start a build. | |||
499 | 634 | ||
500 | In order for the ``checksettings`` command to work, the database must be | 635 | In order for the ``checksettings`` command to work, the database must be |
501 | correctly set up and not have existing data. To be sure the database is | 636 | correctly set up and not have existing data. To be sure the database is |
502 | ready, you can run the following: $ bitbake/lib/toaster/manage.py | 637 | ready, you can run the following: |
503 | syncdb $ bitbake/lib/toaster/manage.py migrate orm $ | 638 | |
504 | bitbake/lib/toaster/manage.py migrate bldcontrol After running these | 639 | .. code-block:: shell |
505 | commands, you can run the ``checksettings`` command. | 640 | |
641 | $ bitbake/lib/toaster/manage.py syncdb | ||
642 | $ bitbake/lib/toaster/manage.py migrate orm | ||
643 | $ bitbake/lib/toaster/manage.py migrate bldcontrol | ||
644 | |||
645 | After running these commands, you can run the ``checksettings`` command. | ||
506 | 646 | ||
507 | .. _toaster-command-runbuilds: | 647 | .. _toaster-command-runbuilds: |
508 | 648 | ||
@@ -510,8 +650,13 @@ commands, you can run the ``checksettings`` command. | |||
510 | ------------- | 650 | ------------- |
511 | 651 | ||
512 | The ``runbuilds`` command launches scheduled builds. Access the command | 652 | The ``runbuilds`` command launches scheduled builds. Access the command |
513 | as follows: $ bitbake/lib/toaster/manage.py runbuilds The ``runbuilds`` | 653 | as follows: |
514 | command checks if scheduled builds exist in the database and then | 654 | |
515 | launches them per schedule. The command returns after the builds start | 655 | .. code-block:: shell |
516 | but before they complete. The Toaster Logging Interface records and | 656 | |
657 | $ bitbake/lib/toaster/manage.py runbuilds | ||
658 | |||
659 | The ``runbuilds`` command checks if scheduled builds exist in the database | ||
660 | and then launches them per schedule. The command returns after the builds | ||
661 | start but before they complete. The Toaster Logging Interface records and | ||
517 | updates the database when the builds complete. | 662 | updates the database when the builds complete. |