diff --git a/.spelling b/.spelling index ae9c1ac6b8bc..eb1e2bc90fca 100644 --- a/.spelling +++ b/.spelling @@ -215,6 +215,7 @@ v2 v2.0 v2.1 v2.10 +v2.10.2 v2.11 v2.12 v2.35.0 diff --git a/docs/argo-server-sso.md b/docs/argo-server-sso.md index 4ab4927748b8..46394dd08064 100644 --- a/docs/argo-server-sso.md +++ b/docs/argo-server-sso.md @@ -197,7 +197,7 @@ workflows.argoproj.io/rbac-rule: "'argo_admins' in groups" ## Filtering groups -> v3.5 and above +> v3.5 and after You can configure `filterGroupsRegex` to filter the groups returned by the OIDC provider. Some use-cases for this include: diff --git a/docs/artifact-visualization.md b/docs/artifact-visualization.md index 962be56d1473..ba68fdf1baff 100644 --- a/docs/artifact-visualization.md +++ b/docs/artifact-visualization.md @@ -1,6 +1,6 @@ # Artifact Visualization -> since v3.4 +> v3.4 and after Artifacts can be viewed in the UI. diff --git a/docs/cluster-workflow-templates.md b/docs/cluster-workflow-templates.md index 3a935534ebac..4d133bf502b1 100644 --- a/docs/cluster-workflow-templates.md +++ b/docs/cluster-workflow-templates.md @@ -56,10 +56,10 @@ spec: value: "hello world" ``` -> 2.9 and after - ### Create `Workflow` from `ClusterWorkflowTemplate` Spec +> v2.9 and after + You can create `Workflow` from `ClusterWorkflowTemplate` spec using `workflowTemplateRef` with `clusterScope: true`. If you pass the arguments to created `Workflow`, it will be merged with cluster workflow template arguments Here is an example for `ClusterWorkflowTemplate` with `entrypoint` and `arguments` @@ -129,15 +129,15 @@ You can create some example templates as follows: argo cluster-template create https://raw.githubusercontent.com/argoproj/argo-workflows/main/examples/cluster-workflow-template/clustertemplates.yaml ``` -The submit a workflow using one of those templates: +Then submit a `Workflow` using one of those templates: ```bash argo submit https://raw.githubusercontent.com/argoproj/argo-workflows/main/examples/cluster-workflow-template/cluster-wftmpl-dag.yaml ``` -> 2.7 and after -> -The submit a `ClusterWorkflowTemplate` as a `Workflow`: +> v2.7 and after + +Then submit a `ClusterWorkflowTemplate` as a `Workflow`: ```bash argo submit --from clusterworkflowtemplate/workflow-template-submittable diff --git a/docs/executor_plugins.md b/docs/executor_plugins.md index 69acb5a729e4..679237f142ae 100644 --- a/docs/executor_plugins.md +++ b/docs/executor_plugins.md @@ -1,6 +1,6 @@ # Executor Plugins -> Since v3.3 +> v3.3 and after ## Configuration diff --git a/docs/high-availability.md b/docs/high-availability.md index fb2a245f2cf4..c1a78de76ee7 100644 --- a/docs/high-availability.md +++ b/docs/high-availability.md @@ -4,7 +4,7 @@ Before v3.0, only one controller could run at once. (If it crashed, Kubernetes would start another pod.) -> v3.0 +> v3.0 and after For many users, a short loss of workflow service may be acceptable - the new controller will just continue running workflows if it restarts. However, with high service guarantees, new pods may take too long to start running workflows. @@ -18,9 +18,9 @@ Budget to prevent this and Pod Priority to recover faster from an involuntary po ## Argo Server -> v2.6 +> v2.6 and after Run a minimum of two replicas, typically three, should be run, otherwise it may be possible that API and webhook requests are dropped. !!! Tip - Consider using [multi AZ-deployment using pod anti-affinity](https://www.verygoodsecurity.com/blog/posts/kubernetes-multi-az-deployments-using-pod-anti-affinity). + Consider [spreading Pods across multiple availability zones](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/). diff --git a/docs/resource-template.md b/docs/resource-template.md index e3b09c7f872b..464f0e04b03d 100644 --- a/docs/resource-template.md +++ b/docs/resource-template.md @@ -1,5 +1,5 @@ # Resource Template -> v2.0 +> v2.0 and after See [Kubernetes Resources](walk-through/kubernetes-resources.md). diff --git a/docs/scaling.md b/docs/scaling.md index 8f9a85aa0032..0b3d4130c089 100644 --- a/docs/scaling.md +++ b/docs/scaling.md @@ -6,7 +6,7 @@ For running large workflows, you'll typically need to scale the controller to ma You cannot horizontally scale the controller. -> v3.0 +> v3.0 and after As of v3.0, the controller supports having a hot-standby for [High Availability](high-availability.md#workflow-controller). diff --git a/docs/suspend-template.md b/docs/suspend-template.md index a749be6d02cd..7737275b29a2 100644 --- a/docs/suspend-template.md +++ b/docs/suspend-template.md @@ -1,5 +1,5 @@ # Suspend Template -> v2.1 +> v2.1 and after See [Suspending](walk-through/suspending.md). diff --git a/docs/variables.md b/docs/variables.md index 669fd622341f..501dc9fd5559 100644 --- a/docs/variables.md +++ b/docs/variables.md @@ -49,7 +49,7 @@ args: [ "{{ inputs.parameters.message }}" ] ### Expression -> Since v3.1 +> v3.1 and after The tag is substituted with the result of evaluating the tag as an expression. @@ -170,7 +170,7 @@ sprig.trim(inputs.parameters['my-string-param']) ### HTTP Templates -> Since v3.3 +> v3.3 and after Only available for `successCondition` diff --git a/docs/workflow-events.md b/docs/workflow-events.md index 0e906b8487b0..ff50178fdba2 100644 --- a/docs/workflow-events.md +++ b/docs/workflow-events.md @@ -1,8 +1,9 @@ # Workflow Events -> v2.7.2 +> v2.7.2 and after -⚠️ Do not use Kubernetes events for automation. Events maybe lost or rolled-up. +!!! Warning "Kubernetes events" + Do not use Kubernetes events for automation as they can be lost or rolled-up. We emit Kubernetes events on certain events. diff --git a/docs/workflow-templates.md b/docs/workflow-templates.md index 1eaf9392a059..30fe124eea22 100644 --- a/docs/workflow-templates.md +++ b/docs/workflow-templates.md @@ -110,7 +110,7 @@ spec: ### Adding labels/annotations to Workflows with `workflowMetadata` -> 2.10.2 and after +> v2.10.2 and after To automatically add labels and/or annotations to Workflows created from `WorkflowTemplates`, use `workflowMetadata`. @@ -282,10 +282,10 @@ to pass in "live" arguments and reference other templates (those other templates This behavior has been problematic and dangerous. It causes confusion and has design inconsistencies. -> 2.9 and after - ### Create `Workflow` from `WorkflowTemplate` Spec +> v2.9 and after + You can create `Workflow` from `WorkflowTemplate` spec using `workflowTemplateRef`. If you pass the arguments to created `Workflow`, it will be merged with workflow template arguments. Here is an example for referring `WorkflowTemplate` as Workflow with passing `entrypoint` and `Workflow Arguments` to `WorkflowTemplate` @@ -333,7 +333,7 @@ Then submit a workflow using one of those templates: argo submit https://raw.githubusercontent.com/argoproj/argo-workflows/main/examples/workflow-template/hello-world.yaml ``` -> 2.7 and after +> v2.7 and after Then submit a `WorkflowTemplate` as a `Workflow`: