The argo CLI is your primary interface to Argo Workflows, and mastering it means understanding how to interact with workflows, templates, and their execution status.
Let’s see it in action. Imagine you’ve submitted a workflow. You’ll want to check its status first.
argo list
This command shows you a list of your recent workflows. You’ll see columns for NAME, STATUS, CREATED, AGE, and DURATION. The STATUS column is key here: Succeeded, Failed, Running, Pending, etc.
Once you’ve identified a workflow of interest, say my-workflow-abc12, you’ll want to dive deeper.
argo get my-workflow-abc12
This command provides a detailed view of the workflow, including its overall status, creation timestamp, duration, and a list of all the steps (pods) that make up the workflow. You’ll see their individual statuses too.
If a workflow failed, you’ll need to inspect the logs of the specific step that failed. You can find the name of the failed step from the argo get output. Let’s assume the failed step was named my-step-xyz789.
argo logs my-workflow-abc12 -c my-step-xyz789
This command streams the logs from the container associated with that specific step within the workflow. This is where you’ll find error messages, stack traces, and other diagnostic information to pinpoint the root cause of the failure.
Now, what if you need to re-run a specific workflow? Perhaps you fixed an issue in your workflow definition or the underlying data.
argo resubmit my-workflow-abc12
This command resubmits the workflow, creating a new workflow instance with the same parameters and definition. It’s a quick way to retry without manually re-creating the workflow object.
Sometimes, you might want to view the manifest of a workflow or a template. This is useful for understanding the structure or for debugging.
argo get my-workflow-abc12 --output yaml
This will output the full YAML definition of the workflow. You can also do this for templates:
argo get my-template-name --template --output yaml
This shows you the YAML definition of a specific template, which is the reusable building block of your workflows.
You can also delete workflows that are no longer needed. This is important for managing resources and keeping your Argo Workflows instance clean.
argo delete my-workflow-abc12
This command removes the specified workflow and all its associated resources. You can also delete multiple workflows using wildcards or by listing them:
argo delete my-workflow-*
If you want to see all the available commands and their options, the help command is your friend.
argo --help
And for specific commands:
argo get --help
This will provide detailed information about the flags and arguments for that particular command, which is invaluable when you’re exploring new functionalities.
The most surprising thing about the argo CLI is how deeply it integrates with Kubernetes’ underlying concepts, allowing you to directly manipulate workflow resources as if they were standard Kubernetes objects, but with workflow-specific intelligence. You’re not just viewing logs; you’re interacting with pods that represent specific steps in a distributed computation.
Finally, if you need to lint your workflow YAML files before submission to catch syntax errors or invalid configurations, you can use:
argo lint ./my-workflow.yaml
This command checks your workflow definition for common errors and adherence to best practices, helping you catch issues before they cause runtime failures.
The next concept you’ll likely encounter is managing dependencies between workflows and using event-driven triggers to automate workflow execution.