Current capability: authoring only#

Workflow designs are currently an authoring preview and cannot be executed. Publishing or restoring a design does not dispatch it or replace the fixed Delivery run lifecycle.

Use this module to design, validate, compare and version a proposed workflow. Use projects and runs for actual deliveries. The stage fields below describe the saved design schema, not an executable custom pipeline.

Create the graph#

  1. Open Workflows and create a workflow, optionally using an available template.
  2. Name the workflow and select a project association when appropriate.
  3. Add the needed stages and configure each one using its available fields.
  4. Connect stages with success, failure or always edges. Check that the graph follows your intended progression.
  5. Validate and inspect every error and warning before saving/publishing.
The editor provides a step library, canvas and configuration inspector. The visible preview notice is important: saved workflow designs do not execute Delivery runs.
The editor provides a step library, canvas and configuration inspector. The visible preview notice is important: saved workflow designs do not execute Delivery runs. View full size ↗

Stage configuration#

StageImportant fields
SourcesourceId and revision.
RenderrendererType and repository path.
PlanWhether live state should be refreshed.
PolicyThe stage’s enforcement choice, including deny, warn or approval. This stage setting is distinct from policy-record enforcement.
ApprovalMinimum approvals and expiry duration.
DeployEnvironment and prune behavior.
VerifyVerification timeout.
WaitDuration and reason.
PromoteDestination environment, sequential/parallel strategy and plan/apply mode.
NotifyRoute, severity and message.

Validate before publishing#

The backend validates schema version, stage types, allowed configuration fields and graph structure. A self-edge, unsupported field or invalid identifier is not fixed by moving a node on the canvas. Use the reported path/node/edge identifier to find the actual issue.

Use the server capability response and validation result as the supported contract. A workflow graph is not a general-purpose shell runner; it stores the recognized design stage types.

Publish, compare and roll back a definition#

  1. Save the draft after validation.
  2. Compare it with the published version to review added, removed and changed stages/connections.
  3. Publish with a meaningful message and inspect the recorded revision.
  4. Use revision history to inspect or restore a prior workflow definition when needed.

Rolling back a workflow definition changes the saved design version only. It is not the same operation as rolling back Kubernetes resources from a delivery run. Save a reusable workflow template only when its IDs/configuration are suitable for the intended future projects.