The Manualstep creates a task for the assigned role group members and blocks the stage execution until the task is either approved or rejected (either through the release dashboard, tasks page, or via the REST API, or via Emails (pipeline roles and users can complete the task)). This is useful when there are manual steps that must be performed in between automated steps executing within a stage.
Approve / Reject Action
Tasks can be approved from tasks page as well, but user members of Approval Role must approve step on release dashboard as there will be no task for them when gate is executed. If user member of Approval Role approves the step, then task is created and approved for any one of approver user's group for reference.
Note that even when more than one Groups are member of Approval Role, only one approval is needed to complete this step.
Administrator can approve or reject manual step.
Since FlexDeploy 8.0, manual step can be rejected, which would mean failure of manual activity and execution will stop.
When using Task page, user can claim the task to work on, at which point other users will see that someone else is working on it and they will not be able to approve or reject also.
...
Field | Description |
|---|---|
Name | The name of the step. |
Description | An optional description for the step. |
Approval Role | The pipeline role which is assigned to this manual step. Optionally, use a Groovy expression to make this field dynamic based on some contextual value (e.g. a property defined on the pipeline, and specified on the release). When using a role script you can dynamically return a key/value pair. For example |
Input Fields | @Since 8.0.0.4 User defined inputs that are used to control behavior within your Pipeline during each execution. Input Fields are assigned values during the execution of this step. These can be accessed in groovy via the ‘Code’ field, but are read-only and cannot be modified. |
Precondition | An optional Groovy script which determines whether the gate or step is applicable during execution. The script has access to variables and methods listed in Pipeline Groovy Variables and Methods. You can find these variables and methods while using the Groovy Editor. The script must return true if the step is applicable, or false otherwise. If no script is provided, the default is to return true (applicable). |
On Error @Before 8.0.0.4 | |
Continue | If checked, any failure will be ignored, and the pipeline execution will continue. |
Notify Pipeline Role | Selects one or more roles from the pipeline definition to notify in case of error. Default role members are defined on the pipeline, and optionally overridden for each release. Optionally, use a Groovy expression to make this field dynamic based on some contextual value (e.g. a property defined on the pipeline, and specified on the release). When using a role script you can dynamically return a key/value pair. For example |
Input Fields
@Since 8.0.0.4 User Input Fields are user defined inputs that are used to control behavior within your Pipeline during each execution. Input Fields are assigned values during the execution of this step. This can be done from the Release Dashboard, Tasks screen, or through Email reply. These can be accessed in groovy via the ‘Code’ field, but are read-only and cannot be modified. Trying to modify an input field variable within a script will result in an error during execution. Similar to other property definition screens like Workflow Properties or Pipeline Properties, Input Fields are highly customizable. However, they are not encrypted and the default value is defined as a script, which will be evaluated at the initialization of this step during execution.
...
Also, if the user stopped the execution by selecting “Stop Execution” when submitting the step, they will have the ability to replay the step/stage again. When this happens, the previous values assigned to input fields or the default value will be present, but the user can still modify them as needed.
...
When completing or stopping a manual step by email, the email will include the list of input fields and relevant information such as code, display name, description, data type, and if the input field is required. If the input field has list data associated with it, then the description will mention the first three items in the list with the following sentence: “Some possible values are: option 1, option 2, option 3”. There are also quick links to auto generate a reply with the proper format for the user to assign values to. Note that in the system Email Settings, “Enable Email Approval” has to be enabled with IMAP Settings configured for the server to process email replies.
...
When replying, make sure to use the words “Complete” or “Stop” along with a note on the same line. For assigning values to input fields, use the following syntax on a new line for each input field: CODE = VALUE. Similarly, using the links in the email will auto generate a reply and populate the necessary input fields in the correct format for the user to assign values to. Default values will initially be assigned to their respective codes. If the execution was replayed, then the previously submitted values will be displayed too, but the default values take priority. Using the screenshot above as an example, the reply email would look something like this. Keep in mind the last 3 lines were included when using one of the reply links.
...