...
The Assignstep provides the ability to assign a value to a workflow variable or a property. Property values that are overridden will keep the new value for the rest of the workflow execution.
...
Field | Description |
|---|---|
Variable | The variable or property that we are assigning to. |
Expression | The expression (groovy) value that should be assigned. |
Error Handler
The Error Handler step essentially provides a try/catch mechanism for your Workflow Definition. The Step itself provides two “scopes” in which nested Workflow Steps can be used. The first being the Default scope and the second being the On Error scope.
...
Should an error occur while processing Steps defined in the Default Scope 1️⃣ , the Workflow Engine will immediately move to the On Error Scope 2️⃣ and start running Steps. The Error Handler Step provides a few configuration options outlined below:
...
Field | Description | ||
|---|---|---|---|
Propagate Error | Determines what action should occur after executing the Steps defined in the On Error Scope
| ||
Error Variable | Once an error occurs it can be useful to get access to the error object in your On Error Scope. Specifying a variable in this input will assign that error object into that variable so it can be accessed.
| ||
Error Message Variable | Identical to Error Variable except it only contains the text of the error instead of the full object. |
If
The If Step is a flow-control operation that allows your Workflow to dictate which Steps should be run depending on conditions.
...
Having said all of that - we are ready to take a look at the available configuration:
Field | Description |
|---|---|
Target Group Override | As mentioned above the Target Group and Target are decided when the Workflow Request form is submitted, should you wish to use a different Target Group, that can be specified here. This will result in a different set of Endpoints being used for Plugin Execution. |
Endpoint Selection | A Target can have multiple Endpoints associated to it. This input allows you to specify which of those Endpoints are considered “candidates” for Plugin Execution. Available options are:
|
Endpoint Execution | Once the list of Endpoint candidates is chosen based on Selection criteria above, we can then decide which of those Endpoints should actually perform Plugin Executions. Available options are:
|
Artifacts Delivery
5️⃣ A Plugin Operation has the ability to Produce or Consume Artifacts from FlexDeploy’s Artifact Repository.
...
The Invoke Test step provides the ability to invoke a group of tests for the Project executing the Workflow. The Step will take into account any filters present in the Test Automation yaml configuration when determining what tests should be run. Several other configuration inputs can be specified to further refine the tests that should be executed.
...
Field | Description |
|---|---|
Test Name | Test Name allows further refinement of the tests considered for execution. Test Name and Test Tag will union the results should both be specified. Allows multiple entries separated by comma. This input is a Groovy Script so be sure to enclose any literal text in quotes. |
Tags | Run specific tests with specific tags in the Test Automation yaml configuration. Test Name and Test Tag will union the results should both be specified. Allows multiple entries separated by comma. This input is a Groovy Script so be sure to enclose any literal text in quotes. |
Test Qualifier | We can configure the Step itself to fail should the test results not meet expectation. The Test Qualifier input determines what those expectations should be. Depending upon the value chosen, Test Qualifier Value may be presented to be filled in. Set to No Qualifier to pass the Step regardless of the results. |
Output Variable | You can optionally assign the result of the Step to an output variable that can be used later in the Workflow. |
Invoke Workflow
The Invoke Workflow Step allows the execution of other Workflows from the current Workflow. This allows common Workflow logic to be isolated and reused where needed.
...
Field | Description |
|---|---|
Workflow | This is the Workflow that should be called. While the field allows calling ANY other active Workflow, it doesn’t necessarily mean that you should. Generally its good practice to have your common Workflow logic created with the Workflow type Other. |
Version Override | By Default, the active version of the invoked Workflow will be used when running this Step. You can however choose a specific version with this input. |
Inputs (if any) | If the invoked Workflow has any defined Workflow Inputs, those will show up in this section. |
Raise Fault
Raise Fault is a Step that will throw a custom error during Workflow execution. This can be useful if you are doing some upfront validation or if you recognize the Target or Endpoint state is not as it should be.
...
Field | Description |
|---|---|
Fault Name | Fault Name should be a shorthand identifier for the particular fault that was thrown. For example CUSTOMERPREFIX_VALIDATION_FAULT |
Fault Details | Fault Details is a longer form description or message of the failure. |
Run Groovy
The Run Groovy Step provides a blank Groovy script with access to all of the Workflow properties, variables, inputs and FlexDeploy utility functions. Think of the Run Groovy script as a catch all that can implement any solution if there is not a specific operation for it.
...