particle-os/debian-koji
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: Task flow diagram

Browse source 
Fixes: https://pagure.io/koji/issue/3267
This commit is contained in:
Tomas Kopecek 2022-03-22 11:43:13 +01:00
parent c92464936d
commit d6a0267571
2 changed files with 36 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

1
docs/source/conf.py
View file

@ -31,6 +31,7 @@ import os
extensions = [
'sphinx.ext.autodoc',
'sphinx.ext.doctest',
'sphinx.ext.graphviz',
]
# Add any paths that contain templates here, relative to this directory.

37
docs/source/writing_koji_code.rst
View file

@ -47,6 +47,41 @@ integrated in Koji's data model, you would need to modify the CLI, Hub,
Builder, and WebUI at a minimum. Alternatively, you could do this with a
plugin, which is far simpler but less flexible.
Tasks' states are following:
* ``FREE`` - Task was created and waits in the queue
* ``OPEN`` - Task was grabbed by some builder and is running now
* ``CLOSED`` - Succesffuly finished task.
* ``CANCELED`` - Task which was either manually cancelled or some sibling task already
failed, so it would be wasteful to continue with this one so parent task
will cancel it.
* ``ASSIGNED`` - Task can be manually (admin) assigned to specific builder bypassing channel
policy. This behaviour can be forbidden via policy, so in some instances this
could be unreachable state.
* ``FAILED`` - Task failed from some reason (typically build process failed)
.. graphviz::
digraph task_states {
"FREE" [color="blue", penwidth=2]
"OPEN" [shape="box", color="orange", penwidth=2]
"CLOSED" [shape="box", color="green", penwidth=2]
"CANCELED" [shape="box", color="yellow", penwidth=2]
"ASSIGNED" [shape="box", color="purple", penwidth=2]
"FAILED" [shape="box", color="red", penwidth=2]
FREE -> OPEN[label="builder picks the task\nand starts it\n[builder]"]
FREE -> ASSIGNED[label="task is assigned\nto specific builder\n[admin]"]
OPEN -> CLOSED[label="task is successfully\nfinished\n[builder]"]
OPEN -> FAILED[label="task fails\n[builder]"]
OPEN -> CANCELED[label="task is automatically\nor manually canceled\n[builder/owner/admin]"]
OPEN -> ASSIGNED[label="task is forced to\nrun on specific builder\n[admin]"]
OPEN -> FREE[label="task is freed\n[admin]"]
ASSIGNED -> OPEN[label="builder starts\nwork on task\n[builder]"]
ASSIGNED -> CANCELED[label="task is automatically\nor manually canceled\n[builder/owner/admin]"]
FAILED -> FREE[label="task is \nresubmitted\n[owner/admin]"]
CANCELED -> FREE[label="task is \nresubmitted\n[owner/admin]"]
}
Component Overview
==================
@ -231,8 +266,6 @@ of each call via the ``result`` property on each ``VirtualCall`` object. (You
must execute the call before accessing the ``.result`` property, or
``VirtualCall`` will raise an exception.)
::
Two parameters affect the behavior of the multicall.
* If the ``strict`` parameter is set to ``True``, the multicall will raise the