Argo Workflows: CAPA practice questions

Argo Workflows is a Kubernetes-native workflow engine. A Workflow resource both defines the work and records the state of its run, so it behaves as a live object. Its spec is essentially a list of templates and an entrypoint: templates behave like functions, and the entrypoint names the one to run first.

Templates come in two groups. Template definitions do the work: container runs a container, script wraps a container around an inline script, and for both the standard output is exported as outputs.result for later steps; resource creates, gets, applies, deletes, replaces or patches cluster objects, and suspend pauses for a duration or until someone resumes the workflow; HTTP, container set and plugin templates also exist. Invocators call other templates: steps and dag. Steps are a list of lists, where the outer list runs in sequence and the items of each inner list run in parallel. A DAG declares tasks with dependencies; tasks without dependencies start immediately and the others wait until the ones they depend on are done.

The depends field gives finer control than plain dependencies by naming the result to wait for, such as task-1.Succeeded, task-2.Failed or Errored, Skipped (its when condition was false), Omitted or Daemoned, combined with &&, || and !. A bare task name is equivalent to Succeeded, Skipped or Daemoned.

Data moves through parameters and artifacts. A template declares inputs.parameters and reads them as {{inputs.parameters.message}}; values in spec.arguments.parameters are global and readable as {{workflow.parameters.name}}, and argo submit -p overrides them, while --entrypoint runs a different template. Artifacts are files or directories: a step declares an output artifact with a path, and a later step receives it as an input with from: {{steps.generate-artifact.outputs.artifacts.hello-art}}, or the tasks prefix inside a DAG. Artifact examples need a configured artifact repository, such as S3-compatible storage.

Control flow features are declared on steps and tasks. when runs a step only if an expression is true, for example comparing an earlier step's outputs.result. Loops come in three forms: withItems over a literal list, withParam over a JSON array, often produced by an earlier step, and withSequence over a range of numbers; loop iterations run in parallel. retryStrategy sets a limit, a retryPolicy of OnFailure (the default), OnError, OnTransientError or Always, and an exponential backoff. An exit handler named in spec.onExit always runs at the end, whether the workflow succeeded or not, and can read {{workflow.status}}, which is Succeeded, Failed or Error, to choose between cleanup and notifications.

Reuse is handled by templates stored in the cluster. A WorkflowTemplate is a namespaced workflow definition; another workflow calls one of its templates with templateRef from a steps or dag template, or starts from the whole definition with workflowTemplateRef, merging any arguments it passes. A ClusterWorkflowTemplate is the cluster-scoped equivalent, referenced with clusterScope: true. A CronWorkflow runs a workflow on a non-empty list of cron schedules, with a concurrencyPolicy of Allow (default), Forbid or Replace, an optional timezone, startingDeadlineSeconds for missed runs, suspend, and history limits of three successful and one failed workflow by default.