===================== Managing the Pipeline ===================== EDP implements a dynamic bundle pipeline through two menu options: **Bundle Pipelines** and **User Tasks**. ------------------- The Bundle Pipeline ------------------- Once the menu option **Bundle Pipelines** (BP) is chosen, users will see a list of BP families. Existing families can have their metadata edited and, in case a family is empty (no revisions), it can be deleted. Revisions are instances of the BP family and cover the different updates made during the work of developing a feature. A BP family is conceived as a group of BP revisions (versions) that execute the same goal. The first step for users to define a pipeline would be to create a new BP family, starting by entering its name and a brief description. After having been saved, the new BP family appears on the list. Select it and click on ``Create Revision`` to define the pipeline in the canvas area. Functionalities to undo, redo, rearrange, center and zoom can be helpful in this design phase. .. figure:: ./image/bp-create-revision-canvas.png :align: center :alt: Bundle Pipeline Creation :target: ./_static/bp-create-revision-canvas-z.png :width: 600px Start (green) and action nodes (gray) form a BP. **Open in new tab to see full-size image**. After defining how the pipeline should look like, by saving it users are asked to provide some comments about the revision, after which step they may press ``Save`` again. The newly created revision will be added to the revisions’ list of the BP family. Updating the Pipeline ===================== Now let us assume that, with time, the pipeline defined for this revision would prove unfit for the job, and users would like to add some tasks to it. Maybe they want to, after QA approval, apply acceleration before transitioning a bundle to be deployed to a device. Also, in case acceleration fails, it might be useful to introduce another user task to check failures and notify developers. In this case, just go to the initial BP family page, that lists the revisions, click on the button labeled ``Update Revision`` and choose ``unlock``. Then work further on the design. After finishing, click ``Save`` and this will create a revision number 2. .. admonition:: Please note :class: my-custom-note The latest revision will be always the one chosen whenever a BP family is required. However, older revisions still need to be kept in case they are still in use. BPs are potentially long running processes, that may execute from few minutes up to several days or even weeks. So whenever the developer wishes to update a BP, there might be already some processes running, and a running pipeline may not be changed. Therefore BP families were designed, that keep the different versions available while waiting for a BP to be updated. ------------------------ Revisions and Executions ------------------------ Once in the BP family page, one can opt for the elimination of a revision. Let us say, after having saved an updated revision 2, a user wants to delete the previous revision 1. In order to disable a revision, just click on the eye icon, which will in turn change into a garbage can: the revision becomes disabled and that is indicated by the value "false" in the column *Enabled*. It is also possible to disable the latest revision: in this case, no event will be able to start this pipeline family, and the family itself can be deleted. However, if some revisions of this family are still running, they will continue to run until execution is finished. While a revision runs, it should not be deleted. In order to check the state of a BP execution, while on the revisions' list of a BP family, click on ``executions``. At this point, by clicking on ``view``, one is be able to navigate through the execution, seeing the action nodes and also the metadata of the events in JSON form. The arrows are used to unfold details of the artifacts. In a general view, all executions can be sorted, keeping track of the ones that are already finished or still running. When the execution is marked as “finished”, the ``delete`` button is enabled for the revision. .. figure:: ./image/BP-finished-started-execution-list.png :align: center :alt: BP execution state :target: ./_static/BP-finished-started-execution-list-z.png :width: 600px Keep track of the BP's execution state. **Open in new tab to see full-size image**. .. admonition:: On Forced Stops :class: my-custom-warning Note that a "Force Delete" option is also offered while the revision is still running. In case of a forced stop, users will be asked to confirm the action by entering “delete” in an input field. This can be convenient, in case an execution hangs due to bugs, or when the server is killed not gracefully and the pipeline does not receive an error status (an error is also taken as a final status), so that the pipeline hangs. To see an example of how a complex BP might look and start interacting with it, go to the **Bundle Pipeline** start page and click on ``Create Demo Pipeline``. Then navigate through its automatically created revision, viewing and editing its design (after choosing ``Unlock``). ---------- User Tasks ---------- The page **User Tasks** lets users view a list of all current tasks. As it is not bound to any environment, it shows the same content for “develop”, “staging” and “release”, providing the users have roles that allow them to see the content and work on it. When a task is chosen, a window pops up, with information like name and description. A user must have a correspondent role, for example “tester”, to be able to see the details of a user task. Under *Pipeline Subject* we can see the entity to which this task is being applied to, that could be an artifact, showing its symbolic name. Let us imagine a bundle pipeline triggered by the event *Artifact Created*. To this event a user task is added named *test1*, with possible results “ok” or “declined”. By an “ok” result, we want to execute further, adding another user task, which we will simply call here “ok pressed”. If you click on this specific task, it can be *owned* by you with a click on ``Assign to me``, so nobody else can work on it. Once that is done, that task can be again unassigned or resolved, by choosing one of the answers predefined during the user task definition: let us say you choose “ok” and then click on “Fulfill Task”. .. figure:: ./image/user-task.png :align: center :alt: User Tasks :target: ./_static/user-task-z.png :width: 600px Tasks: assign, choose the answers and fulfill. **Open in new tab to see full-size image**. When the task is fulfilled, if you navigate to **Bundle Pipelines** and choose the correspondent BP family and revision, you will be able to see a finished execution: by clicking on ``view``, information will be shown, like event name, artifacts that were uploaded and by whom, and also information about the user tasks involved in the bundle pipeline, including their states and the selected answers. :doc:`← Previous Page ` | :doc:`Next Page → `