...
Workflow Type | Description |
|---|---|
Build | The first step in the Build/Deploy model. The Build Workflow most commonly does the following tasks:
|
Deploy | The Deploy Workflow is most commonly the next workflow run. Its duties consist of reading or consuming Artifacts published during the Build Workflow and uploading or deploying those Artifacts to your Deploy Target. An example of this could be taking html/css/javascript bundled during build and uploading to a Azure to be served. |
PreDeploy | Prior to running the aforementioned Deploy Workflow, you can optionally run a PreDeploy Workflow. The PreDeploy Workflow can use the Build Artifacts and running any checks prior to the Deploy Workflow executing. Some examples of this could be:
|
Test Definition | The last Workflow run is a Workflow testing the previous deployment on the Deploy Target. A common example being running some form REST tests, using something like Postman, to validate the Deployment. |
Utility | Utility Workflows fall outside of the typical Build and Deploy process outlined above. Utility Workflows don’t consume or produce any artifacts and are most commonly used to run adhoc on demand logic on a Target Server. A few examples would be:
Note that Utility Workflows can only be used by a specific Project Classification called |
Other | Lastly, the black sheep of the family, Other Workflows cannot be used by any Project directly. Their only usage is to have common Workflow logic that can be called from the Workflow types listed before. |
...
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 under certain depending on conditions.
...
At minimum, the If Step requires an If Condition 1️⃣. One more Else If Conditions can optionally be added 2️⃣ and finally an optional Else block can be added 3️⃣. Every condition gets the full suite of available variables and properties at its disposal. Each condition/block can also run any number of Steps. A full example implementation of the If Step is below:
...
The configuration for Invoke Plugin can be quite daunting, but we will break it down into manageable pieces.
...
2️⃣ Plugin Inputs are 1 of 3 ways a Plugin Operation can ask for receive configuration values from the user, the . The other 2 being are Project Properties and Target Properties. The Plugin Inputs presented depend entirely upon the chose chosen Plugin and Plugin Operation, as such, more . More detailed information about specific Plugin Inputs can be found in the respective Plugin Guides.
...
3️⃣ Plugin Operations can optionally return 0 or more Plugin Outputs. A Plugin Output is any meaningful piece of data that was calculated during Plugin Execution, for example the JDBC Plugin’s compileInvalid operation returns 4 Outputs:
...
Any Plugin Output can be assigned to a Workflow Variable. Doing so allows the Output to be used elsewhere in the Workflow! .
Endpoint Specification
4️⃣ Generally the Endpoint Specification does not need to be touched or modified. However it can still be good to understand what it is and why its present.
...
Raise Fault is a Step that will throw a custom error during Workflow execution. This can be useful if you are doing some up front upfront validation or if you recognize the Target or Endpoint state is not as it should be.
...