Argo Workflow templates: CAPA practice questions

The word template means two different things in Argo Workflows, and the documentation itself calls the collision unfortunate. A template, in lower case, is one entry in the templates list of a workflow and works like a function: it has inputs, outputs and a body. A WorkflowTemplate is a separate cluster resource that stores a reusable workflow definition, including one or more of those templates.

There are nine template types in two groups. Template definitions do work: container runs an image, script runs an inline script in an image and exposes its standard output as outputs.result, resource creates, applies, patches or deletes a Kubernetes object, suspend waits for a duration or for someone to resume the workflow, and container set, HTTP and plugin cover more specialised cases. Template invocators call other templates: steps runs them as a list of stages, and dag runs them as tasks with dependencies. A workflow names one template as its entrypoint, and that template usually is a steps or dag template that calls the rest.

A WorkflowTemplate is namespaced. Another workflow can call a single template from it with templateRef, giving the WorkflowTemplate name and the template name, from inside a steps or dag template. A workflow can also be created from the whole definition with workflowTemplateRef; any arguments the new workflow passes are merged with the arguments defined in the WorkflowTemplate. A ClusterWorkflowTemplate is the cluster-scoped equivalent, so teams in every namespace can share it, and a reference to it adds clusterScope: true.

A CronWorkflow wraps a workflow spec in a schedule. Its schedules field must be a non-empty list of cron expressions, which replaced the older single schedule field, and an optional timezone sets the clock it reads. concurrencyPolicy decides what happens when a run is due while an earlier one is still going: Allow, the default, starts it anyway, Forbid skips it and Replace removes the old run first. startingDeadlineSeconds lets a run that was missed during a controller outage still start, and history limits keep three successful and one failed workflow by default. A CronWorkflow can be paused with suspend instead of being deleted.