Built-in workflow step types
The platform provides built-in support for the following workflow step definitions. You may use any of the steps when defining the workflow that is used to deploy an application.
|Workflow step type||Description|
|step-group||Define a subgroup of steps in the workflow|
|apply-application-in-parallel||Deploys all the components in parallel|
|apply-application||Deploy all components following the standard procedure|
|apply-component||Deploy a single component|
|apply-remaining||Deploy the remaining components and traits|
|deploy||Deploy components applying a set of policies|
|notification||Send a message to a webhook|
|webhook||Send a webhook request to a URL|
|suspend||Suspend the deployment of pending components and traits|
Common options for workflow steps
The specification of a workflow step provides common options to improve the overall workflow experience that is not dependent on the specific step types. The following paragraphs describe different behaviors that can be added to the workflow.
A timeout can be added to define a maximum time for the system to wait for a step to finish before being marked as failed. This is useful for workflow steps that interact with third party systems.
apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: my-app spec: components: ... workflow: steps: - name: step-that-may-fail type: my-custom-step timeout: 30s
Forcing the step execution on failure
If a workflow step fails, the following steps will not be executed by default. To force the execution of a workflow step, it is possible to use the if clause. The following snippet shows an example workflow that will always send a notification even if the previous step fails.
apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: my-app spec: components: ... workflow: steps: - name: step-that-may-fail type: my-custom-deploy - name: slack-message if: always type: notification
Referencing a workflow
An alternative to embed the workflow inside the Application entity is to create it separately and reference it from within the application. Notice that the workflow should exist before deploying the application. The following example shows an application referencing an external workflow.
apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: my-app spec: components: ... workflow: ref: my-application-workflow
apiVersion: core.oam.dev/v1alpha1 kind: Workflow metadata: name: my-application-workflow steps: ...
- Check out the list of built-in components.
- Check out the list of built-in traits.
- Check out the list of built-in policies.
- Review the Application and Environments core concepts.
- Follow the tutorial to deploying a custom application