docs: fix typos (#24666)

Signed-off-by: jpbotelho <jpbotelho.costa@gmail.com>

docs/developer-guide/development-cycle.md

@@ -7,7 +7,7 @@
 ## Preface 
 When you have developed and possibly manually tested the code you want to contribute, you should ensure that everything builds correctly. Commit your changes locally and perform the following steps, for each step the commands for both local and virtualized toolchain are listed. 
 
-### Docker priviliges for virtualized toolchain users
+### Docker privileges for virtualized toolchain users
 [These instructions](toolchain-guide.md#docker-privileges) are relevant for most of the steps below 
 
 ### Using Podman for virtualized toolchain users

docs/developer-guide/index.md

@@ -28,7 +28,7 @@ For backend and frontend contributions, that require a full building-testing-run
 ## Contributing to Argo CD Notifications documentation
 
 This guide will help you get started quickly with contributing documentation changes, performing the minimum setup you'll need.
-The notificaions docs are located in [notifications-engine](https://github.com/argoproj/notifications-engine) Git repository and require 2 pull requests: one for the `notifications-engine` repo and one for the `argo-cd` repo.
+The notifications docs are located in [notifications-engine](https://github.com/argoproj/notifications-engine) Git repository and require 2 pull requests: one for the `notifications-engine` repo and one for the `argo-cd` repo.
 For backend and frontend contributions, that require a full building-testing-running-locally cycle, please refer to [Contributing to Argo CD backend and frontend ](index.md#contributing-to-argo-cd-backend-and-frontend) 
 
 ### Fork and clone Argo CD repository

docs/developer-guide/tilt.md

@@ -18,7 +18,7 @@
 To remove all deployed resources in your local cluster including CRDs, run `tilt down` from the root of the repo. 
 
 ### Port Forwarding
-Port forwarding is automatically setup from the cluster to localhost host for the folling ports:
+Port forwarding is automatically setup from the cluster to localhost host for the following ports:
 
 | Deployment | API | Metrics | Webhook | Debug |
 |------------|-----|---------|---------|-------|

docs/operator-manual/config-management-plugins.md

@@ -331,7 +331,7 @@ If you don't need to set any environment variables, you can set an empty plugin
 > and let the automatic discovery to identify the plugin.
 
 > [!NOTE]
-> If a CMP renders blank manfiests, and `prune` is set to `true`, Argo CD will automatically remove resources. CMP plugin authors should ensure errors are part of the exit code. Commonly something like `kustomize build . | cat` won't pass errors because of the pipe. Consider setting `set -o pipefail` so anything piped will pass errors on failure.
+> If a CMP renders blank manifests, and `prune` is set to `true`, Argo CD will automatically remove resources. CMP plugin authors should ensure errors are part of the exit code. Commonly something like `kustomize build . | cat` won't pass errors because of the pipe. Consider setting `set -o pipefail` so anything piped will pass errors on failure.
 
 > [!NOTE]
 > If a CMP command fails to gracefully exit on `ARGOCD_EXEC_TIMEOUT`, it will be forcefully killed after an additional timeout of `ARGOCD_EXEC_FATAL_TIMEOUT`.

docs/operator-manual/metrics.md

@@ -271,7 +271,7 @@ Scraped at the `argocd-commit-server:8087/metrics` endpoint.
 
 | Metric                                                  |   Type    | Description                                          |
 | ------------------------------------------------------- | :-------: | ---------------------------------------------------- |
-| `argocd_commitserver_commit_pending_request_total`      |   guage   | Number of pending commit requests.                   |
+| `argocd_commitserver_commit_pending_request_total`      |   gauge   | Number of pending commit requests.                   |
 | `argocd_commitserver_git_request_duration_seconds`      | histogram | Git requests duration seconds.                       |
 | `argocd_commitserver_git_request_total`                 |  counter  | Number of git requests performed by commit server    |
 | `argocd_commitserver_commit_request_duration_seconds`   | histogram | Commit requests duration seconds.                    |

docs/operator-manual/signed-release-assets.md

@@ -117,7 +117,7 @@ slsa-verifier verify-artifact argocd-linux-amd64 \
   --source-tag v2.7.0
 ```
 
-If you only want to verify up to the major or minor verion of the source repository tag (instead of the full tag), use the `--source-versioned-tag` which performs semantic versioning verification:
+If you only want to verify up to the major or minor version of the source repository tag (instead of the full tag), use the `--source-versioned-tag` which performs semantic versioning verification:
 
 ```shell
 slsa-verifier verify-artifact argocd-linux-amd64 \

docs/operator-manual/upgrading/2.6-2.7.md

@@ -74,7 +74,7 @@ This would become :
       if: resource.kind == "Pod" || resource.kind == "Deployment"
 ```
 
-Read the full [documentation](../deep_links.md) to see all possible combinations of values accessible fo each category of links.
+Read the full [documentation](../deep_links.md) to see all possible combinations of values accessible of each category of links.
 
 ## Support of `helm.sh/resource-policy` annotation
 

docs/user-guide/private-repositories.md

@@ -437,7 +437,7 @@ You can also manage SSH known hosts entries in a declarative, self-managed ArgoC
 
 ## Helm
 
-Helm charts can be sourced from protected Helm repositories or OCI registries. You can configure access to protected Helm charts by using either the CLI or the UI by speciying `helm` as the _type_ of HTTPS based repository.
+Helm charts can be sourced from protected Helm repositories or OCI registries. You can configure access to protected Helm charts by using either the CLI or the UI by specifying `helm` as the _type_ of HTTPS based repository.
 
 Using the CLI:
 

docs/user-guide/source-hydrator.md

@@ -207,7 +207,7 @@ git clone https://git.example.com/owner/repo.git
 cd repo
 
 # Build the image and get the new image tag
-# <cusom build logic here>
+# <custom build logic here>
 
 # Get the commit information
 author=$(git show -s --format="%an <%ae>")

docs/user-guide/sync-options.md

@@ -327,7 +327,7 @@ When client-side apply migration is enabled:
 2. During a server-side apply sync operation, it will:
    - Perform a client-side-apply with the specified field manager
    - Move the 'last-applied-configuration' annotation to be managed by the specified manager
-   - Perform the server-side apply, which will auto migrate all the fields under the manager that owns the 'last-applied-configration' annotation.
+   - Perform the server-side apply, which will auto migrate all the fields under the manager that owns the 'last-applied-configuration' annotation.
 
 This feature is based on Kubernetes' [client-side apply migration KEP](https://github.com/alexzielenski/enhancements/blob/03df8820b9feca6d2cab78e303c99b2c9c0c4c5c/keps/sig-cli/3517-kubectl-client-side-apply-migration/README.md), which provides the auto migration from client-side to server-side apply.