Skip to main content
This lesson shows how to define an Argo Workflow as a Directed Acyclic Graph (DAG) by declaring task dependencies instead of listing steps sequentially. Using a DAG makes it natural to express parallelism, join points, and complex dependency relationships between tasks. Overview
  • Entrypoint: main — a DAG template that declares four tasks: A, B, C, and D.
  • All tasks use the same container template echo-message (based on busybox) which echoes a parameter provided to the task.
  • Dependencies:
    • A has no dependencies and runs first.
    • B and C both depend on A, so they run in parallel after A completes.
    • D depends on both B and C and runs only after both have finished.
If a task has no dependencies it becomes runnable immediately. Multiple tasks that become runnable at the same time will execute in parallel (subject to executor and cluster limits).
Task summary Example workflow (Argo Workflow YAML)
Execution order (step-by-step)
  1. Task A runs first because it has no dependencies.
  2. When A completes, both B and C become runnable and execute concurrently (subject to resource limits).
  3. After both B and C finish, D becomes runnable and runs (it depends on B and C).
  4. The workflow completes once D finishes.
Viewing status, logs, and common CLI commands Example task log output (each task echoes its message)
Container command executed for each task
Best practices & notes
  • Use DAGs when you need parallelism or non-linear execution flows. For strict linear flows, a steps-based template may be simpler.
  • Keep resource and concurrency limits in mind; “runnable” tasks may wait if cluster limits are reached.
  • Prefer clear task names and parameter values so logs and UIs are easier to read.
Links and references This simple DAG demonstrates how to control execution order by declaring dependencies between tasks rather than writing an explicit linear sequence—enabling parallel runs and join points with minimal YAML.

Watch Video