========================== Understanding the Pipeline ========================== The goal of this section is to support the understanding of the Bundle Pipeline (BP). As conceived in EDP, Bundle Pipelines were designed to help users define workflows to process features. The pipelines consist of **start nodes**, or events, that activate the workflow, plus **action nodes** and the connections between them. Some of the events are predefined, like *Artifact Created* and *Artifact Published*. Those are start nodes that trigger execution by firing a sequence of actions. If a workflow should be activated every time a user uploads a bundle, *Artifact Created* will be the start node; when the bundle is to transition between stages, *Promote Artifact* is the node that triggers the action, after which tests follow that will validate the transition. Currently in EDP the following **action nodes** are implemented: - User Task [#f1]_ - Accelerate Artifact - Deploy Artifact - Publish Artifact - Reject Artifact - Promote Artifact - Control Artifact .. admonition:: Please note :class: my-custom-note Being implemented by EDP as an action node, the acceleration of a bundle implies the availability of the JAR Accelerator tool from aicas, which requires a valid license. Also mandatory for the acceleration process is the configuration of a JARA target, to be found under Settings, in the EDP web portal. For more information, see :ref:`this section `. In case the license expires, or if no license file is available please contact **support@aicas.com**. --------------------------- What happens on the Backend --------------------------- The bundle pipeline basically involves three entities: Handlers, Orchestrator and Node Managers. As entry point, the event handler listens for different events and searches for matching pipelines in the database, where the BP definitions, as well as execution logs, are stored. .. figure:: ./image/BP-Overview-Ka.png :align: center :alt: intro image The backend elements of a bundle pipeline If a match is found, the event handler will supply the event and the BP definition to the Orchestrator, that will start the processing. Upon receiving this information, the Orchestrator identifies the **start node** and the sequence of actions, according to the connections. It does not process the nodes itself, rather delegating this to the Node Manager, which has a set of Handlers for each node type. Let us take a User Task as an example: after getting this **action node** from the Orchestrator and identifying it as User Task, the Node Manager passes the object to a User Task Handler. The UT Handler processes it and returns the result, for example an artifact, to the Node Manager. This will simply forward the artifact to the Orchestrator, which will then deliver it to the next node in the sequence. This goes on and on, until there are no longer any unprocessed nodes. Only then will the Orchestrator mark the Bundle Pipeline as finished in the database. --------------------- Defining the Pipeline --------------------- The choice of the menu option **Bundle Pipelines** leads you to a list of all available BP families. The different versions are the updates that developers produced along the line, to execute the same goal. To start their designs, users can create a new BP family. It is also possible to extend an existing family, by clicking on the button ``revisions``, choosing a version and selecting ``view/edit``. Remember that a family can only be deleted if it contains no revisions. Drag and drop the nodes offered in the canvas area to define the BP. A color code rules that start nodes (events) are depicted as green boxes, while action nodes are gray boxes. ------------------------ An Example, Step by Step ------------------------ Let us say we want to define the workflow that follows the upload of an artifact. At first, we would select the event *Artifact Created*. After this start node is chosen, all other green boxes disappear, as a safety feature to avoid invalid BPs due to multiple start points. After a start event is placed, users will want to define some actions. One action node available is *User Task*, for which users must define a result. For example, a user task could be named *Approve Artifact*. Just link the pipeline trigger (“out”) to the defined action node (“in”). After providing a small description, users must specify which role someone must have, in order to perform the task. Note that users can extend a basic *Test* role, adding privileges according to the features being tested. The user that creates a specific action node defines possible results to be expected, specifying the values with **+** or **-**. Once this user task *Approve Artifact* is saved, whenever it gets activated users will be able to choose one of two predefined options, for example ``approved`` or ``declined``, available at the top right corner of the box. As further development, in case of artifact approval, the pipeline flow could lead to acceleration and, as a next action, *Deploy Artifact*. A tighter way to control the pipeline would be to direct the workflow to the node *Promote Artifact* following up the artifact approval and before applying any other action. The field *target environment* lists stages other than the current one, allowing the pipeline to move forward. EDP allows the configuration of any amount of action nodes, chaining sequences of tasks as requested by the use case. After defined, a bundle pipeline can be either saved or cleared. .. admonition:: Recommendation :class: my-custom-warning When defining bundle pipelines, keep your user tasks atomic, representing some simple questions that generate explicit results, for there is currently no way to enter extended results’ descriptions. ------------------------- Who defines the Pipeline? ------------------------- At the end of the day that depends on how the company is structured, and if workflows are centrally defined or independently decided by developers. Whichever way, it will be implemented through :doc:`roles and permissions <./roles-and-permissions>`. In the EDP web portal, just go to **Settings** and choose **Privileges**. Then click on *Create Privileges* and select front end permissions. Start to type: you will be able to see the permissions featuring the prefix **bp**, which relate to each of the nodes around the bundle pipeline activity. :doc:`← Previous Page ` | :doc:`Next Page → ` .. rubric:: Footnotes .. [#f1] A user task is an action to be customized by the user that defines the BP.