trigger declares how a workflow may start

What workflow.trigger is

trigger declares the intended entry policy for a workflow graph: manual, schedule, or webhook.

It is not the scheduler or HTTP endpoint itself. Those platform concerns live outside the DSL; this block records the contract the platform should use.

What it contains

• type — Manual by default, or schedule/webhook when declared.
• cron — Required for a schedule trigger.
• No graph logic — Dependencies and failure policies remain on steps.

Entry policy is not execution order

Trigger answers when or how the graph becomes eligible to start. Once started, depends_on still decides which nodes can run.

Run the complete example

Copy this manifest from the verified documentation project, then run it from the repository root.

workflow:
  version: "1.0"
  name: docs_workflow
  description: Two actions used by the DSL documentation.
  trigger: {type: manual}
  steps:
    - name: prepare
      type: action
      action: log
      params: {message: "Preparation complete."}
      retry: {max: 2, delay: 0, backoff: fixed}
    - name: publish
      type: action
      action: log
      params: {message: "Publication complete."}
      depends_on: [prepare]
      when: "1 == 1"
      on_failure: fail

hdrctl workflow run examples/tutorial/dsl-elements/workflow.yaml

  ✓  Step 'prepare' OK (0.0s)
  ✓  Step 'publish' OK (0.0s)

  ✅ Workflow 'docs_workflow' completed in 0.0s — 2/2 steps OK

The relevant command syntax, copied from hdrctl workflow run --help:

hdrctl workflow run PATH
  PATH          path to workflow.yaml
  --lang LANG   interface language
  -h, --help    show command help

Close by

• name and version — graph identity
• steps — graph nodes
• retry — failure attempts
• workflow.yaml — complete manifest
• Reference — trigger fields