Skip to main content Link Menu Expand (external link) Document Search Copy Copied
Napptive docs

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.

Timeout

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:
  ...

What’s next