Merge branch 'main' into improve-ad-docs

Author: colinbowern

public/docs/i/1000/argo-cd/steps/argocd-step-verification.webp

@@ -0,0 +1 @@
+{"width":1019,"height":290,"updated":"2026-03-03T01:07:53.858Z"}

public/docs/i/2000/argo-cd/steps/argocd-step-verification.webp

@@ -10,17 +10,17 @@ hideInThisSectionHeader: true
 
 By default, a Kubernetes cluster will use `docker.io` as the image registry when none is defined. This means that if an image is defined without the registry, for example `nginx/nginx:latest`, then this image will be resolved from the `docker.io` registry.
 
-This default registry can be changed via the [kubeadm init --image-repository](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/) command & flag. When executing the [Update Argo CD Image Tags](/docs/argo-cd/steps/update-application-image-tags) step, Octopus will exactly match the specified image using the registry and name.
+This default registry can be changed via the [kubeadm init --image-repository](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/) command and flag. When executing the [Update Argo CD Image Tags](/docs/argo-cd/steps/update-application-image-tags) step, Octopus will exactly match the specified image using the registry and name.
 
-If the default cluster version has been changed, then Octopus needs to be made aware so that it correctly matches images.
+If the default cluster registry has been changed, then Octopus needs to be made aware so that it correctly matches images.
 
 :::div{.info}
 If the cluster default registry has not been changed, then you do not need to do the following steps.
 :::
 
 ## Setting the default container registry annotation
 
-To make Octopus aware of a clusters default registry, an annotation needs to be added to each cluster object in Argo CD instance.
+To make Octopus aware of a cluster's default registry, an annotation needs to be added to each cluster object in Argo CD instance.
 
 The annotation and value is:
 
@@ -34,7 +34,7 @@ For example:
 argo.octopus.com/default-container-registry : my-company-registry.com
 ```
 
-This should be added via the Argo CD web UI by selecting from the menu Settings --> Clusters, then editing the annotations
+This should be added via the Argo CD web UI by navigating to **Settings ➜ Clusters**, then editing the annotations
 field on the cluster of interest.
 
 ![Default Registry Cluster Annotation](/docs/img/argo-cd/default-registry-annotation.png)

public/docs/i/600/argo-cd/steps/argocd-step-verification.webp

@@ -49,7 +49,7 @@ Note that while the scoping annotation for the project/environment is defined fo
 
 ## Details
 
-For Octopus to be able to update the tag of a container image, it must know the fully qualified name, including the registry. An example of a fully qualified name is: `docker.io/nginx/nginx:1.29.1`. This is important so that Octopus doesn't erroneously update an image from a different registry. For example: images may be set to be sourced from a company-managed registry, where only vetted & tested tags are added. In this case, we don't want to update an image that looks like this: `my-company-registry.com/nginx/nginx:1.18.1`.
+For Octopus to be able to update the tag of a container image, it must know the fully qualified name, including the registry. An example of a fully qualified name is: `docker.io/nginx/nginx:1.29.1`. This is important so that Octopus doesn't erroneously update an image from a different registry. For example: images may be set to be sourced from a company-managed registry, where only vetted and tested tags are added. In this case, we don't want to update an image that looks like this: `my-company-registry.com/nginx/nginx:1.18.1`.
 
 As described above however, the structure of Helm values files can vary significantly. Rather than Octopus guessing (and possibly making a mistake), the onus is on you to specify a Helm-template string that builds a fully qualified name. Octopus can then use this to match on containers being updated and can then use this information to update the specific Helm value that contains the image tag.
 

public/docs/i/x/argo-cd/steps/argocd-step-verification.png

@@ -47,7 +47,7 @@ spec:
     path: ./    
 ```
 
-If the source is named, then the annotations must also source-scoped.
+If the source is named, then the annotations must also be source-scoped.
 
 ```yaml
 apiVersion: argoproj.io/v1alpha1
@@ -127,15 +127,15 @@ spec:
   ...
 ```
 
-### Generating the yaml annotations
+### Generating the YAML annotations
 
-To help generate the correct annotations, in the Octopus UI there is a form that allows for easy selection of projects, environments and/or tenants and the correct scoping annotations will be generated for you.
+To help generate the correct annotations, the Octopus UI provides a form that lets you select projects, environments, and/or tenants, and the correct scoping annotations will be generated for you.
 
 To find this form go to:
 
 1. Navigate to **Infrastructure ➜ Argo CD Instances**, then click the name of the relevant Argo CD instance
 2. On the Argo CD instance Settings page, click the **Generate Scoping Annotations** button
-3. In the drawer, you can select a **Project**, **Environment** and optionally a **Tenant**. The annotation yaml will be generated and can be copied directly into the manifest.
+3. In the drawer, you can select a **Project**, **Environment** and optionally a **Tenant**. The annotation YAML will be generated and can be copied directly into the manifest.
 
 :::figure
 ![Generate Scoping Annotations drawer](/docs/img/argo-cd/generate-scoping-annotations-drawer.png)

public/docs/img/argo-cd/steps/argocd-step-verification.png

@@ -4,7 +4,7 @@ pubDate: 2025-09-15
 modDate: 2026-02-22
 title: Argo CD deployments with Octopus
 navTitle: Overview
-description: Octopus Deploy can help you manage your Argo CD applications navigate lifecycle promotion
+description: Octopus Deploy manages your Argo CD applications' environment promotion
 navSection: Argo CD
 navOrder: 28
 hideInThisSectionHeader: true
@@ -18,12 +18,12 @@ Octopus makes it easy to improve your Argo CD deployments with environment model
 
 Argo CD excels at synchronizing manifests to clusters and provides a powerful UI to verify and troubleshoot deployments.
 
-However, it treats each of your applications as independent entities, meaning there's no `codified` relationship between staging and production installations of your applications. Because of this, you need to manage this staging/production relationship and promotion between them through external mechanisms, eg:
+However, it treats each of your applications as independent entities, meaning there's no *codified* relationship between staging and production installations of your applications. Because of this, you need to manage this staging/production relationship and promotion between them through external mechanisms, e.g.:
 
 - Manual file manipulations
 - Custom scripts, run automatically or via Jenkins/CI tooling
 
-The Octopus/Argo integration means your Argo Applications can be updated and deployed via an Octopus Deployment Process (or runbook). Which in turn means your Applications can be safely promoted through a controlled lifecycle.
+The Octopus/Argo integration means your Argo Applications can be updated and deployed via an Octopus Deployment Process (or runbook), which in turn means your Applications can be safely promoted through a controlled lifecycle.
 
 Octopus makes integrating and deploying with Argo CD simple: