> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Argo Workflow Specification
> Explains Argo Workflows CRD, YAML structure, template types, container templates, submission methods, and best practices for authoring reusable Kubernetes automation pipelines.
In this lesson we examine the Argo Workflow specification and how to author reusable automation pipelines as Kubernetes custom resources.
Argo Workflows is implemented as a Kubernetes Custom Resource Definition (CRD), which lets you define complex CI/CD and automation pipelines using familiar YAML files. A workflow is a structured sequence of automated tasks that together accomplish a goal — commonly used in DevOps for application deployment, testing, and promotion.
Key components of an Argo Workflow manifest:
* Header: Kubernetes metadata (apiVersion, kind, metadata).
* spec: Describes workflow behavior and templates that perform work.
The following sections explain the structure, common template types, and how to submit a workflow.
## Workflow file structure
A typical workflow YAML contains the following top-level parts:
* Header: `apiVersion`, `kind`, and `metadata`.
* Metadata: you can specify `name` or `generateName`. Use `generateName` to avoid collisions when submitting the same manifest multiple times — Argo appends a unique suffix.
* spec: the core of the workflow. Important fields:
* `entrypoint`: the name of the template that starts execution.
* `templates`: a list of reusable templates. Templates describe tasks and can reference each other.
Use generateName when you want to submit the same workflow multiple times without name collisions. Each submission will get a unique suffix appended to the provided generateName.
## Template types (overview)
Templates are the building blocks of workflows. Argo supports several template types for different use cases:
| Template Type | Use Case | Notes |
| ------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| container | Run a container image | Maps directly to a Kubernetes container spec (`image`, `command`, `args`, `env`, `volumeMounts`, `resources`) |
| script | Run inline scripts in various runtimes | Useful for quick logic without building a container image |
| steps | Define sequential steps | A list of templates executed in sequence |
| dag | Define directed acyclic graph execution | Supports complex dependency graphs and parallelism |
| resource | Create or modify Kubernetes resources | Useful for applying manifests or CRs as part of the workflow |
Templates can be composed — steps or dag templates reference container/script/resource templates to perform tasks.
## Container templates
Container templates accept the same fields as a Kubernetes Pod container spec. This means you can use:
* image
* command and args
* env and envFrom
* volumeMounts and volumes
* resources
Because the container template mirrors Kubernetes, you can use existing YAML knowledge when defining tasks.
Example container-template workflow:
```yaml theme={null}
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: cowsay-
spec:
entrypoint: cowsay-template
templates:
- name: cowsay-template
container:
image: rancher/cowsay
command: ["cowsay"]
args: ["Argo Workflow!!!!"]
```
## Submitting a workflow
You can submit workflows with either the Argo UI or the CLI.
CLI example (submits to the `argo` namespace):
```bash theme={null}
# submit workflow.yml to the 'argo' namespace
argo submit -n argo workflow.yml
```
The Argo UI is available if your Argo server is exposed; it provides a visual representation of templates, DAGs, and steps.
The `entrypoint` must match one of the template names defined under `templates`. If it does not, the workflow will fail to start.
## Practical tips and best practices
* Use `generateName` for recurring or CI-driven workflow submissions to avoid manual name management.
* Keep templates small and reusable — compose complex workflows from simple building blocks (container/script/steps/dag).
* Use `resources` and `resourceLimits` to avoid noisy scheduling and to communicate expected resource usage.
* Version control your workflow manifests alongside application code or infrastructure repositories for traceability.
## Quick reference: spec fields
| Field | Description |
| ------------------ | -------------------------------------------- |
| entrypoint | Name of the template to execute first |
| templates | List of named templates used by the workflow |
| arguments | Pass parameters into templates and workflows |
| volumes | Shared volumes available to templates |
| serviceAccountName | Service account used by workflow pods |
## Links and references
* [Argo Workflows documentation](https://argoproj.github.io/argo-workflows/)
* [Argo Workflows UI](https://argoproj.github.io/argo-workflows/ui/)
* [Argo CLI documentation](https://argoproj.github.io/argo-workflows/cli_workflows/)
* [Kubernetes CRDs](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
* [Kubernetes Pod and container specs](https://kubernetes.io/docs/concepts/workloads/pods/)
Notes:
* The `container` section within a template maps directly to a Kubernetes container spec and supports `env`, `volumeMounts`, and `resources`.
* Always ensure the `entrypoint` value matches a defined template name under `templates`.