From 65350789e8e593f348a7b8179d70b56407c9a429 Mon Sep 17 00:00:00 2001 From: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com> Date: Fri, 23 Jan 2026 08:00:47 -0500 Subject: [PATCH] docs: small fixes for mkdocs warnings (#26112) Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com> Co-authored-by: Nitish Kumar --- docs/developer-guide/index.md | 28 +++++++++---------- docs/index.md | 4 +-- docs/operator-manual/app-any-namespace.md | 2 +- .../applicationset/Application-Deletion.md | 2 +- .../applicationset/Generators-Cluster.md | 8 +++--- .../applicationset/Template.md | 2 +- .../applicationset/Use-Cases.md | 4 +-- docs/operator-manual/cluster-bootstrapping.md | 2 +- .../config-management-plugins.md | 2 +- .../operator-manual/notifications/examples.md | 4 +-- docs/operator-manual/notifications/index.md | 2 +- docs/operator-manual/security.md | 2 +- docs/operator-manual/upgrading/1.6-1.7.md | 4 +-- docs/operator-manual/upgrading/1.8-2.0.md | 2 +- docs/operator-manual/upgrading/2.12-2.13.md | 2 +- docs/operator-manual/upgrading/2.14-3.0.md | 2 +- docs/operator-manual/upgrading/2.3-2.4.md | 2 +- docs/operator-manual/upgrading/3.1-3.2.md | 2 +- docs/operator-manual/user-management/okta.md | 2 +- docs/operator-manual/web_based_terminal.md | 2 +- docs/operator-manual/webhook.md | 2 +- docs/proposals/headless-argocd.md | 2 +- .../multiple-sources-for-applications.md | 2 +- ...parameterized-config-management-plugins.md | 2 +- docs/proposals/proxy-extensions.md | 2 +- docs/proposals/server-side-apply.md | 4 +-- docs/security_considerations.md | 2 +- docs/user-guide/annotations-and-labels.md | 4 +-- docs/user-guide/helm.md | 2 +- docs/user-guide/multiple_sources.md | 2 +- docs/user-guide/private-repositories.md | 2 +- docs/user-guide/status-badge.md | 2 +- 32 files changed, 54 insertions(+), 54 deletions(-) diff --git a/docs/developer-guide/index.md b/docs/developer-guide/index.md index 72c10007e9..8fe16cbd76 100644 --- a/docs/developer-guide/index.md +++ b/docs/developer-guide/index.md @@ -22,8 +22,8 @@ For backend and frontend contributions, that require a full building-testing-run ### Submit your PR - [Before submitting a PR](submit-your-pr.md#before-submitting-a-pr) -- [Choose a correct title for your PR](submit-your-pr.md#choose-a-correct-title-for-your-pr) -- [Perform the PR template checklist](submit-your-pr.md#perform-the-PR-template-checklist) +- [Choose a correct title for your PR](submit-your-pr.md#title-of-the-pr) +- [Perform the PR template checklist](submit-your-pr.md#pr-template-checklist) ## Contributing to Argo CD Notifications documentation @@ -36,8 +36,8 @@ For backend and frontend contributions, that require a full building-testing-run ### Submit your PR to notifications-engine - [Before submitting a PR](submit-your-pr.md#before-submitting-a-pr) -- [Choose a correct title for your PR](submit-your-pr.md#choose-a-correct-title-for-your-pr) -- [Perform the PR template checklist](submit-your-pr.md#perform-the-PR-template-checklist) +- [Choose a correct title for your PR](submit-your-pr.md#title-of-the-pr) +- [Perform the PR template checklist](submit-your-pr.md#pr-template-checklist) ### Install Go on your machine - [Install Go](development-environment.md#install-go) @@ -45,8 +45,8 @@ For backend and frontend contributions, that require a full building-testing-run ### Submit your PR to argo-cd - [Contributing to notifications-engine](dependencies.md#notifications-engine-githubcomargoprojnotifications-engine) - [Before submitting a PR](submit-your-pr.md#before-submitting-a-pr) -- [Choose a correct title for your PR](submit-your-pr.md#choose-a-correct-title-for-your-pr) -- [Perform the PR template checklist](submit-your-pr.md#perform-the-PR-template-checklist) +- [Choose a correct title for your PR](submit-your-pr.md#title-of-the-pr) +- [Perform the PR template checklist](submit-your-pr.md#pr-template-checklist) ## Contributing to Argo CD backend and frontend @@ -71,11 +71,11 @@ As is the case with the development process, this document is under constant cha ### Perform the development cycle - [Set kubectl context to argocd namespace](development-cycle.md#set-kubectl-context-to-argocd-namespace) - [Pull in all build dependencies](development-cycle.md#pull-in-all-build-dependencies) -- [Generate API glue code and other assets](development-cycle.md#generate-API-glue-code-and-other-assets) +- [Generate API glue code and other assets](development-cycle.md#generate-api-glue-code-and-other-assets) - [Build your code and run unit tests](development-cycle.md#build-your-code-and-run-unit-tests) - [Lint your code base](development-cycle.md#lint-your-code-base) - [Run e2e tests](development-cycle.md#run-end-to-end-tests) -- How to contribute to documentation: [build and run documentation site](docs-site/) on your machine for manual testing +- How to contribute to documentation: [build and run documentation site](docs-site.md) on your machine for manual testing ### Run and debug Argo CD locally - [Run Argo CD on your machine for manual testing](running-locally.md) @@ -83,13 +83,13 @@ As is the case with the development process, this document is under constant cha ### Submit your PR - [Before submitting a PR](submit-your-pr.md#before-submitting-a-pr) -- [Understand the Continuous Integration process](submit-your-pr.md#understand-the-continuous-integration-process) -- [Choose a correct title for your PR](submit-your-pr.md#choose-a-correct-title-for-your-pr) -- [Perform the PR template checklist](submit-your-pr.md#perform-the-PR-template-checklist) -- [Understand the CI automated builds & tests](submit-your-pr.md#automated-builds-&-tests) +- [Understand the Continuous Integration process](submit-your-pr.md#continuous-integration-process) +- [Choose a correct title for your PR](submit-your-pr.md#title-of-the-pr) +- [Perform the PR template checklist](submit-your-pr.md#pr-template-checklist) +- [Understand the CI automated builds & tests](submit-your-pr.md#automated-builds-tests) - [Understand & make sure your PR meets the CI code test coverage requirements](submit-your-pr.md#code-test-coverage) -Need help? Start with the [Contributors FAQ](faq/) +Need help? Start with the [Contributors FAQ](faq.md) ## Contributing to Argo CD dependencies - [Contributing to argo-ui](dependencies.md#argo-ui-components-githubcomargoprojargo-ui) @@ -98,7 +98,7 @@ Need help? Start with the [Contributors FAQ](faq/) ## Extensions and Third-Party Applications * [UI Extensions](extensions/ui-extensions.md) * [Proxy Extensions](extensions/proxy-extensions.md) -* [Config Management Plugins](../operator-manual/config-management-plugins/) +* [Config Management Plugins](../operator-manual/config-management-plugins.md) ## Contributing to Argo Website The Argo website is maintained in the [argo-site](https://github.com/argoproj/argo-site) repository. diff --git a/docs/index.md b/docs/index.md index 0c194682f5..534e0dd503 100644 --- a/docs/index.md +++ b/docs/index.md @@ -26,9 +26,9 @@ kubectl apply -n argocd --server-side --force-conflicts -f https://raw.githubuse The `--server-side --force-conflicts` flags are required due to CRD size limitations. See the [getting started guide](getting_started.md) for details. -Follow our [getting started guide](getting_started.md). Further user oriented [documentation](user-guide/) +Follow our [getting started guide](getting_started.md). Further user oriented [documentation](user-guide/index.md) is provided for additional features. If you are looking to upgrade Argo CD, see the [upgrade guide](./operator-manual/upgrading/overview.md). -Developer oriented [documentation](developer-guide/) is available for people interested in building third-party integrations. +Developer oriented [documentation](developer-guide/index.md) is available for people interested in building third-party integrations. ## How it works diff --git a/docs/operator-manual/app-any-namespace.md b/docs/operator-manual/app-any-namespace.md index 3a58ce8d32..425bf28b5e 100644 --- a/docs/operator-manual/app-any-namespace.md +++ b/docs/operator-manual/app-any-namespace.md @@ -23,7 +23,7 @@ This feature can only be enabled and used when your Argo CD is installed as a cl Also, while technically not necessary, it is strongly suggested that you switch the application tracking method from the default `label` setting to either `annotation` or `annotation+label`. The reasoning for this is, that application names will be a composite of the namespace's name and the name of the `Application`, and this can easily exceed the 63 characters length limit imposed on label values. Annotations have a notably greater length limit. -To enable annotation based resource tracking, refer to the documentation about [resource tracking methods](../../user-guide/resource_tracking/) +To enable annotation based resource tracking, refer to the documentation about [resource tracking methods](../user-guide/resource_tracking.md) ## Implementation details diff --git a/docs/operator-manual/applicationset/Application-Deletion.md b/docs/operator-manual/applicationset/Application-Deletion.md index 33885cf2b5..8b2a4529e0 100644 --- a/docs/operator-manual/applicationset/Application-Deletion.md +++ b/docs/operator-manual/applicationset/Application-Deletion.md @@ -10,7 +10,7 @@ The end result is that when an ApplicationSet is deleted, the following occurs ( - The `ApplicationSet` resource itself is deleted - Any `Application` resources that were created from this `ApplicationSet` (as identified by owner reference) will be deleted - Any deployed resources (`Deployments`, `Services`, `ConfigMaps`, etc) on the managed cluster, that were created from that `Application` resource (by Argo CD), will be deleted. - - Argo CD is responsible for handling this deletion, via [the deletion finalizer](../../../user-guide/app_deletion/#about-the-deletion-finalizer). + - Argo CD is responsible for handling this deletion, via [the deletion finalizer](../../user-guide/app_deletion.md#about-the-deletion-finalizer). - To preserve deployed resources, set `.syncPolicy.preserveResourcesOnDeletion` to true in the ApplicationSet. Thus the lifecycle of the `ApplicationSet`, the `Application`, and the `Application`'s resources, are equivalent. diff --git a/docs/operator-manual/applicationset/Generators-Cluster.md b/docs/operator-manual/applicationset/Generators-Cluster.md index 8b27fa5952..a29e32e735 100644 --- a/docs/operator-manual/applicationset/Generators-Cluster.md +++ b/docs/operator-manual/applicationset/Generators-Cluster.md @@ -1,6 +1,6 @@ # Cluster Generator -In Argo CD, managed clusters [are stored within Secrets](../../declarative-setup/#clusters) in the Argo CD namespace. The ApplicationSet controller uses those same Secrets to generate parameters to identify and target available clusters. +In Argo CD, managed clusters [are stored within Secrets](../declarative-setup.md#clusters) in the Argo CD namespace. The ApplicationSet controller uses those same Secrets to generate parameters to identify and target available clusters. For each cluster registered with Argo CD, the Cluster generator produces parameters based on the list of items found within the cluster secret. @@ -17,7 +17,7 @@ It automatically provides the following parameter values to the Application temp > Use the `nameNormalized` parameter if your cluster name contains characters (such as underscores) that are not valid for Kubernetes resource names. This prevents rendering invalid Kubernetes resources with names like `my_cluster-app1`, and instead would convert them to `my-cluster-app1`. -Within [Argo CD cluster Secrets](../../declarative-setup/#clusters) are data fields describing the cluster: +Within [Argo CD cluster Secrets](../declarative-setup.md#clusters) are data fields describing the cluster: ```yaml kind: Secret data: @@ -105,7 +105,7 @@ The cluster selector also supports set-based requirements, as used by [several c ### Deploying to the local cluster -In Argo CD, the 'local cluster' is the cluster upon which Argo CD (and the ApplicationSet controller) is installed. This is to distinguish it from 'remote clusters', which are those that are added to Argo CD [declaratively](../../declarative-setup/#clusters) or via the [Argo CD CLI](../../getting_started.md/#5-register-a-cluster-to-deploy-apps-to-optional). +In Argo CD, the 'local cluster' is the cluster upon which Argo CD (and the ApplicationSet controller) is installed. This is to distinguish it from 'remote clusters', which are those that are added to Argo CD [declaratively](../declarative-setup.md#clusters) or via the [Argo CD CLI](../../getting_started.md#5-register-a-cluster-to-deploy-apps-to-optional). The cluster generator will automatically target both local and non-local clusters, for every cluster that matches the cluster selector. @@ -137,7 +137,7 @@ However, if you do wish to target both local and non-local clusters, while also 4. Leave all other fields unchanged. 5. Click *Save*. -These steps might seem counterintuitive, but the act of changing one of the default values for the local cluster causes the Argo CD Web UI to create a new secret for this cluster. In the Argo CD namespace, you should now see a Secret resource named `cluster-(cluster suffix)` with label `argocd.argoproj.io/secret-type": "cluster"`. You may also create a local [cluster secret declaratively](../../declarative-setup/#clusters), or with the CLI using `argocd cluster add "(context name)" --in-cluster`, rather than through the Web UI. +These steps might seem counterintuitive, but the act of changing one of the default values for the local cluster causes the Argo CD Web UI to create a new secret for this cluster. In the Argo CD namespace, you should now see a Secret resource named `cluster-(cluster suffix)` with label `argocd.argoproj.io/secret-type": "cluster"`. You may also create a local [cluster secret declaratively](../declarative-setup.md#clusters), or with the CLI using `argocd cluster add "(context name)" --in-cluster`, rather than through the Web UI. ### Fetch clusters based on their K8s version diff --git a/docs/operator-manual/applicationset/Template.md b/docs/operator-manual/applicationset/Template.md index a486592fbc..bce8c6487f 100644 --- a/docs/operator-manual/applicationset/Template.md +++ b/docs/operator-manual/applicationset/Template.md @@ -27,7 +27,7 @@ Here is the template subfield from a Cluster generator: For details on all available parameters (like `.name`, `.nameNormalized`, etc.) please refer to the [Cluster Generator docs](./Generators-Cluster.md). -The template subfields correspond directly to [the spec of an Argo CD `Application` resource](../../declarative-setup/#applications): +The template subfields correspond directly to [the spec of an Argo CD `Application` resource](../declarative-setup.md#applications): - `project` refers to the [Argo CD Project](../../user-guide/projects.md) in use (`default` may be used here to utilize the default Argo CD Project) - `source` defines from which Git repository to extract the desired Application manifests diff --git a/docs/operator-manual/applicationset/Use-Cases.md b/docs/operator-manual/applicationset/Use-Cases.md index a13c659807..da65dc44b7 100644 --- a/docs/operator-manual/applicationset/Use-Cases.md +++ b/docs/operator-manual/applicationset/Use-Cases.md @@ -27,7 +27,7 @@ In this use case, we may use either the List, Cluster, or Git generators of the - *List generator*: Administrators maintain two `ApplicationSet` resources, one for each application (Workflows and Prometheus), and include the list of clusters they wish to target within the List generator elements of each. - With this generator, adding/removing clusters requires manually updating the `ApplicationSet` resource's list elements. - *Cluster generator*: Administrators maintain two `ApplicationSet` resources, one for each application (Workflows and Prometheus), and ensure that all new cluster are defined within Argo CD. - - Since the Cluster generator automatically detects and targets the clusters defined within Argo CD, [adding/remove a cluster from Argo CD](../../declarative-setup/#clusters) will automatically cause Argo CD Application resources (for each application) to be created by the ApplicationSet controller. + - Since the Cluster generator automatically detects and targets the clusters defined within Argo CD, [adding/remove a cluster from Argo CD](../declarative-setup.md#clusters) will automatically cause Argo CD Application resources (for each application) to be created by the ApplicationSet controller. - *Git generator*: The Git generator is the most flexible/powerful of the generators, and thus there are a number of different ways to tackle this use case. Here are a couple: - Using the Git generator `files` field: A list of clusters is kept as a JSON file within a Git repository. Updates to the JSON file, through Git commits, cause new clusters to be added/removed. - Using the Git generator `directories` field: For each target cluster, a corresponding directory of that name exists in a Git repository. Adding/modifying a directory, through Git commits, would trigger an update for the cluster that has shares the directory name. @@ -60,7 +60,7 @@ The *self-service use case* seeks to allow developers (as the end users of a mul - Deploy to multiple clusters, in an automated fashion, using Argo CD - But, in both cases, to empower those developers to be able to do so without needing to involve a cluster administrator (to create the necessarily Argo CD Applications/AppProject resources on their behalf) -One potential solution to this use case is for development teams to define Argo CD `Application` resources within a Git repository (containing the manifests they wish to deploy), in an [app-of-apps pattern](../../cluster-bootstrapping/#app-of-apps-pattern), and for cluster administrators to then review/accept changes to this repository via merge requests. +One potential solution to this use case is for development teams to define Argo CD `Application` resources within a Git repository (containing the manifests they wish to deploy), in an [app-of-apps pattern](../cluster-bootstrapping.md#app-of-apps-pattern-alternative), and for cluster administrators to then review/accept changes to this repository via merge requests. While this might sound like an effective solution, a major disadvantage is that a high degree of trust/scrutiny is needed to accept commits containing Argo CD `Application` spec changes. This is because there are many sensitive fields contained within the `Application` spec, including `project`, `cluster`, and `namespace`. An inadvertent merge might allow applications to access namespaces/clusters where they did not belong. diff --git a/docs/operator-manual/cluster-bootstrapping.md b/docs/operator-manual/cluster-bootstrapping.md index 095b8a77ab..5f422fe91d 100644 --- a/docs/operator-manual/cluster-bootstrapping.md +++ b/docs/operator-manual/cluster-bootstrapping.md @@ -220,7 +220,7 @@ See [Deleting Applications in the UI](../user-guide/app_deletion.md#deleting-app ### Ignoring differences in child applications -To allow changes in child apps without triggering an out-of-sync status, or modification for debugging etc, the app of apps pattern works with [diff customization](../user-guide/diffing/). The example below shows how to ignore changes to syncPolicy and other common values. +To allow changes in child apps without triggering an out-of-sync status, or modification for debugging etc, the app of apps pattern works with [diff customization](../user-guide/diffing.md). The example below shows how to ignore changes to syncPolicy and other common values. ```yaml spec: diff --git a/docs/operator-manual/config-management-plugins.md b/docs/operator-manual/config-management-plugins.md index c35247af03..b03bc5d19b 100644 --- a/docs/operator-manual/config-management-plugins.md +++ b/docs/operator-manual/config-management-plugins.md @@ -457,7 +457,7 @@ Sidecar plugins can use either discovery rules or a plugin name to match Applica then you have to explicitly specify the plugin by name in the app spec or else that particular plugin will not match any app. If you want to use discovery instead of the plugin name to match applications to your plugin, write rules applicable to -your plugin [using the instructions above](#1-write-the-plugin-configuration-file) and add them to your configuration +your plugin [using the instructions above](#write-discovery-rules-for-your-plugin) and add them to your configuration file. To use the name instead of discovery, update the name in your application manifest to `-` diff --git a/docs/operator-manual/notifications/examples.md b/docs/operator-manual/notifications/examples.md index bcd4be753d..ab5a2ea61a 100644 --- a/docs/operator-manual/notifications/examples.md +++ b/docs/operator-manual/notifications/examples.md @@ -31,7 +31,7 @@ data: send: [on-deployed-template] ``` -This, as explained in the [triggers section](triggers/#avoid-sending-same-notification-too-often), will generate a notification when the app is synced and healthy. We then need to create a subscription for the webhook integration: +This, as explained in the [triggers section](triggers.md#avoid-sending-same-notification-too-often), will generate a notification when the app is synced and healthy. We then need to create a subscription for the webhook integration: ```yaml apiVersion: argoproj.io/v1alpha1 @@ -125,7 +125,7 @@ data: send: [on-deployed-template] ``` -Now, with the setup above, a sync will send the list of images to your Slack application. For more information about integratin with Slack, see the [Slack integration guide](/operator-manual/notifications/services/slack/). +Now, with the setup above, a sync will send the list of images to your Slack application. For more information about integratin with Slack, see the [Slack integration guide](services/slack.md). ### Deduplicating images diff --git a/docs/operator-manual/notifications/index.md b/docs/operator-manual/notifications/index.md index 0e77679f38..28aec8f7d3 100644 --- a/docs/operator-manual/notifications/index.md +++ b/docs/operator-manual/notifications/index.md @@ -112,4 +112,4 @@ metadata: > When the same notification service and trigger are defined in controller level configuration and application level configuration, > both notifications will be sent according to its own configuration. -[Defining and using secrets within notification templates](templates/#defining-and-using-secrets-within-notification-templates) function is not available when flag `--self-service-notification-enable` is on. +[Defining and using secrets within notification templates](templates.md#defining-and-using-secrets-within-notification-templates) function is not available when flag `--self-service-notification-enable` is on. diff --git a/docs/operator-manual/security.md b/docs/operator-manual/security.md index e2391ed742..1280d9bb56 100644 --- a/docs/operator-manual/security.md +++ b/docs/operator-manual/security.md @@ -173,7 +173,7 @@ kubectl edit clusterrole argocd-application-controller ``` > [!TIP] -> If you want to deny Argo CD access to a kind of resource then add it as an [excluded resource](declarative-setup.md#resource-exclusion). +> If you want to deny Argo CD access to a kind of resource then add it as an [excluded resource](declarative-setup.md#resource-exclusioninclusion). ## Auditing diff --git a/docs/operator-manual/upgrading/1.6-1.7.md b/docs/operator-manual/upgrading/1.6-1.7.md index 4cc6bcaac5..7ec10733dc 100644 --- a/docs/operator-manual/upgrading/1.6-1.7.md +++ b/docs/operator-manual/upgrading/1.6-1.7.md @@ -29,7 +29,7 @@ data: ## New RBAC rules for GnuPG related features -The [GnuPG feature](../../../user-guide/gpg-verification) has introduced a new +The [GnuPG feature](../../user-guide/gpg-verification.md) has introduced a new RBAC resource in Argo CD, `gpgkeys`. Please adapt your RBAC rules with the appropriate permissions. The least set of @@ -40,6 +40,6 @@ p, , gpgkeys, get, *, allow ``` More information can be found in the -[documentation](../../../user-guide/gpg-verification#rbac-rules-for-managing-gnupg-keys) +[documentation](../../user-guide/gpg-verification.md#rbac-rules-for-managing-gnupg-keys) From here on you can follow the [regular upgrade process](./overview.md). diff --git a/docs/operator-manual/upgrading/1.8-2.0.md b/docs/operator-manual/upgrading/1.8-2.0.md index fa74d15420..2d1b0b3a20 100644 --- a/docs/operator-manual/upgrading/1.8-2.0.md +++ b/docs/operator-manual/upgrading/1.8-2.0.md @@ -10,7 +10,7 @@ hours to avoid user-visible failures. ## Environment variables expansion -Argo CD supports using [environment variables](../../../user-guide/build-environment/) in +Argo CD supports using [environment variables](../../user-guide/build-environment.md) in config management tools parameters. The expansion logic has been improved and now expands missing environment variables into an empty string. diff --git a/docs/operator-manual/upgrading/2.12-2.13.md b/docs/operator-manual/upgrading/2.12-2.13.md index 6dd401b510..5a31e1964c 100644 --- a/docs/operator-manual/upgrading/2.12-2.13.md +++ b/docs/operator-manual/upgrading/2.12-2.13.md @@ -6,7 +6,7 @@ Note that bundled Helm version has been upgraded from 3.15.2 to 3.15.4. ## Custom Resource Actions for Flux Resources -[`Custom Resource Actions`](../resource_actions.md#Custom-Resource-Actions) have been added for Flux Resources. +[`Custom Resource Actions`](../resource_actions.md#custom-resource-actions) have been added for Flux Resources. The following actions are now available: | Custom Resource | Supported Actions | diff --git a/docs/operator-manual/upgrading/2.14-3.0.md b/docs/operator-manual/upgrading/2.14-3.0.md index 9fe0464a4b..5b20460846 100644 --- a/docs/operator-manual/upgrading/2.14-3.0.md +++ b/docs/operator-manual/upgrading/2.14-3.0.md @@ -62,7 +62,7 @@ For users without a default policy, add this policy to `policy.csv`: `p, role:gl Explicitly add a `logs, get` policy to every role that has a policy for `applications, get` or for `applications, *`. This is the recommended way to maintain the principle of least privilege. Similar to the way access to Applications are currently managed, access to logs can be either granted on a Project scope level (Project resource) or on the `argocd-rbac-cm` ConfigMap level. -See this [example](../upgrading/2.3-2.4.md#example-1) for more details. +See this [example](../upgrading/2.3-2.4.md#example) for more details. ### Default `resource.exclusions` configurations diff --git a/docs/operator-manual/upgrading/2.3-2.4.md b/docs/operator-manual/upgrading/2.3-2.4.md index 2c47b62da7..c51f400f66 100644 --- a/docs/operator-manual/upgrading/2.3-2.4.md +++ b/docs/operator-manual/upgrading/2.3-2.4.md @@ -197,7 +197,7 @@ that uses the Service Account for auth), be sure to test before deploying the 2. ### Remove the shared volume from any sidecar plugins -As a security enhancement, [sidecar plugins](../config-management-plugins.md#option-2-configure-plugin-via-sidecar) +As a security enhancement, [sidecar plugins](../config-management-plugins.md#sidecar-plugin) no longer share the /tmp directory with the repo-server. If you have one or more sidecar plugins enabled, replace the /tmp volume mount for each sidecar to use a volume specific diff --git a/docs/operator-manual/upgrading/3.1-3.2.md b/docs/operator-manual/upgrading/3.1-3.2.md index 40b3372fe8..512c317d8d 100644 --- a/docs/operator-manual/upgrading/3.1-3.2.md +++ b/docs/operator-manual/upgrading/3.1-3.2.md @@ -6,7 +6,7 @@ ### Hydration paths must now be non-root -Source hydration (with [Source Hydrator](../../../user-guide/source-hydrator/)) now requires that every application specify a non-root path. +Source hydration (with [Source Hydrator](../../user-guide/source-hydrator.md)) now requires that every application specify a non-root path. Using the repository root (for example, "" or ".") is no longer supported. This change ensures that hydration outputs are isolated to a dedicated subdirectory and prevents accidental overwrites or deletions of important files stored at the root, such as CI pipelines, documentation, or configuration files. diff --git a/docs/operator-manual/user-management/okta.md b/docs/operator-manual/user-management/okta.md index f5cdf40443..62d5da8bbb 100644 --- a/docs/operator-manual/user-management/okta.md +++ b/docs/operator-manual/user-management/okta.md @@ -71,7 +71,7 @@ The settings are largely the same with a few changes in the Okta app configurati Using this deployment model, the user connects to the private Argo CD UI and the Okta authentication flow seamlessly redirects back to the private UI URL. -Often this public endpoint is exposed through an [Ingress object](../../ingress/#private-argo-cd-ui-with-multiple-ingress-objects-and-byo-certificate). +Often this public endpoint is exposed through an [Ingress object](../ingress.md#private-argo-cd-ui-with-multiple-ingress-objects-and-byo-certificate). 1. Update the URLs in the Okta app's General settings diff --git a/docs/operator-manual/web_based_terminal.md b/docs/operator-manual/web_based_terminal.md index 2ad36496c0..404090b33b 100644 --- a/docs/operator-manual/web_based_terminal.md +++ b/docs/operator-manual/web_based_terminal.md @@ -56,7 +56,7 @@ to `exec` into pods This can be added either to the `argocd-cm` `Configmap` manifest or an `AppProject` manifest. - See [RBAC Configuration](rbac.md#exec-resource) for more info. + See [RBAC Configuration](rbac.md#the-exec-resource) for more info. ## Changing allowed shells diff --git a/docs/operator-manual/webhook.md b/docs/operator-manual/webhook.md index 6b7f10e1b4..f08de8835f 100644 --- a/docs/operator-manual/webhook.md +++ b/docs/operator-manual/webhook.md @@ -7,7 +7,7 @@ this delay from polling, the API server can be configured to receive webhook eve Git webhook notifications from GitHub, GitLab, Bitbucket, Bitbucket Server, Azure DevOps and Gogs. The following explains how to configure a Git webhook for GitHub, but the same process should be applicable to other providers. -Application Sets use a separate webhook configuration for generating applications. [Webhook support for the Git Generator can be found here](applicationset/Generators-Git/#webhook-configuration). +Application Sets use a separate webhook configuration for generating applications. [Webhook support for the Git Generator can be found here](applicationset/Generators-Git.md#webhook-configuration). > [!NOTE] > The webhook handler does not differentiate between branch events and tag events where the branch and tag names are diff --git a/docs/proposals/headless-argocd.md b/docs/proposals/headless-argocd.md index 51bee5ce85..76528f85ac 100644 --- a/docs/proposals/headless-argocd.md +++ b/docs/proposals/headless-argocd.md @@ -68,7 +68,7 @@ The `Headless Argo CD` is not intended to deprecate any of the existing operatio #### Headless Installation Manifests -In order to simplify installation of Argo CD without API we need introduce `headless/install.yaml` in [manifests](../../manifests) directory. +In order to simplify installation of Argo CD without API we need to introduce `headless/install.yaml` in the `manifests` directory. The installation manifests should include only non HA controller, repo-server, Redis components, and RBAC. #### Headless CLI diff --git a/docs/proposals/multiple-sources-for-applications.md b/docs/proposals/multiple-sources-for-applications.md index b94cc62361..4bc464e179 100644 --- a/docs/proposals/multiple-sources-for-applications.md +++ b/docs/proposals/multiple-sources-for-applications.md @@ -180,7 +180,7 @@ As a user, I have an Application that uses the [elasticsearch](https://github.co https://github.com/argoproj/argo-cd/issues/677 #### Use case 2: -As per one of the [comment]((https://github.com/argoproj/argo-cd/issues/2789#issuecomment-562495307)) on the issue [Helm chart + values files from Git](https://github.com/argoproj/argo-cd/issues/2789): +As per one of the [comment](https://github.com/argoproj/argo-cd/issues/2789#issuecomment-562495307) on the issue [Helm chart + values files from Git](https://github.com/argoproj/argo-cd/issues/2789): ``` We have a Helm Chart which is used in 30+ Services and each of them is customized for 3 possible environments. Replicating this Chart 30 times without a centralized Repo looks dirty. Can be a show stopper for the whole migration. diff --git a/docs/proposals/parameterized-config-management-plugins.md b/docs/proposals/parameterized-config-management-plugins.md index 153b7fb9b7..2bed1ad81e 100644 --- a/docs/proposals/parameterized-config-management-plugins.md +++ b/docs/proposals/parameterized-config-management-plugins.md @@ -55,7 +55,7 @@ management tools (Helm, Kustomize, etc.). + [Security Considerations](#security-considerations) - [Increased scripting](#increased-scripting) + [Risks and Mitigations](#risks-and-mitigations) - + [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy) + + [Upgrade / Downgrade Strategy](#upgrade-downgrade-strategy) * [Drawbacks](#drawbacks) * [Alternatives](#alternatives) diff --git a/docs/proposals/proxy-extensions.md b/docs/proposals/proxy-extensions.md index ccbbf5687c..7d977b68e8 100644 --- a/docs/proposals/proxy-extensions.md +++ b/docs/proposals/proxy-extensions.md @@ -29,7 +29,7 @@ Enable UI extensions to use a backend service. * [Use cases](#use-cases) * [Security Considerations](#security-considerations) * [Risks and Mitigations](#risks-and-mitigations) - * [Upgrade / Downgrade](#upgrade--downgrade) + * [Upgrade / Downgrade](#upgrade-downgrade) * [Drawbacks](#drawbacks) * [Open Questions](#open-questions) diff --git a/docs/proposals/server-side-apply.md b/docs/proposals/server-side-apply.md index 1fa6c98e31..7d50c50f57 100644 --- a/docs/proposals/server-side-apply.md +++ b/docs/proposals/server-side-apply.md @@ -39,7 +39,7 @@ describes how ArgoCD can leverage SSA during syncs. * [[G-5] Register a proper manager](#g-5-register-a-proper-manager) * [Non-Goals](#non-goals) * [Proposal](#proposal) - * [Non-Functional Requirements](#non-functional-requirements) + * [Non-Functional Requirements](#non-goals) * [Use cases](#use-cases) * [[UC-1]: enable SSA at the controller level](#uc-1-as-a-user-i-would-like-enable-ssa-at-the-controller-level-so-all-application-are-applied-server-side) * [[UC-2]: enable SSA at the Application level](#uc-2-as-a-user-i-would-like-enable-ssa-at-the-application-level-so-all-resources-are-applied-server-side) @@ -48,7 +48,7 @@ describes how ArgoCD can leverage SSA during syncs. * [Risks and Mitigations](#risks-and-mitigations) * [[R-1] Supported K8s version check](#r-1-supported-k8s-version-check) * [[R-2] Alternating Server-Side Client-Side syncs](#r-2-alternating-server-side-client-side-syncs) - * [Upgrade / Downgrade](#upgrade--downgrade) + * [Upgrade / Downgrade](#upgrade-downgrade) * [Drawbacks](#drawbacks) --- diff --git a/docs/security_considerations.md b/docs/security_considerations.md index 660f417084..652905ef83 100644 --- a/docs/security_considerations.md +++ b/docs/security_considerations.md @@ -122,7 +122,7 @@ An attacker could use this information in an attempt to deduce the state of the **Mitigation and/or workaround:** The recommended mitigation as described in the user documentation is to use SSO integration. The default admin password -should only be used for initial configuration and then [disabled](../operator-manual/user-management/#disable-admin-user) +should only be used for initial configuration and then [disabled](operator-manual/user-management/index.md#disable-admin-user) or at least changed to a more secure password. ### CVE-2020-8827 - Insufficient anti-automation/anti-brute force diff --git a/docs/user-guide/annotations-and-labels.md b/docs/user-guide/annotations-and-labels.md index 57589624c6..c12c8e23db 100644 --- a/docs/user-guide/annotations-and-labels.md +++ b/docs/user-guide/annotations-and-labels.md @@ -7,8 +7,8 @@ | argocd.argoproj.io/application-set-refresh | ApplicationSet | `"true"` | Added when an ApplicationSet is requested to be refreshed by a webhook. The ApplicationSet controller will remove this annotation at the end of reconciliation. | | argocd.argoproj.io/compare-options | any | [see compare options docs](compare-options.md) | Configures how an app's current state is compared to its desired state. | | argocd.argoproj.io/hook | any | [see resource hooks docs](resource_hooks.md) | Used to configure [resource hooks](resource_hooks.md). | -| argocd.argoproj.io/hook-delete-policy | any | [see resource hooks docs](resource_hooks.md#hook-deletion-policies) | Used to set a [resource hook's deletion policy](resource_hooks.md#hook-deletion-policies). | -| argocd.argoproj.io/manifest-generate-paths | Application | [see scaling docs](../operator-manual/high_availability.md#webhook-and-manifest-paths-annotation) | Used to avoid unnecessary Application refreshes, especially in mono-repos. | +| argocd.argoproj.io/hook-delete-policy | any | [see sync waves docs](sync-waves.md#hook-lifecycle-and-cleanup) | Used to set a [resource hook's deletion policy](sync-waves.md#hook-lifecycle-and-cleanup). | +| argocd.argoproj.io/manifest-generate-paths | Application | [see scaling docs](../operator-manual/high_availability.md#manifest-paths-annotation) | Used to avoid unnecessary Application refreshes, especially in mono-repos. | | argocd.argoproj.io/managed-by-url | Application | A valid http(s) URL | Specifies the URL of the Argo CD instance managing the application. Used to correctly link to applications managed by a different Argo CD instance. See [managed-by-url docs](../operator-manual/managed-by-url.md) for details. | | argocd.argoproj.io/refresh | Application | `normal`, `hard` | Indicates that app needs to be refreshed. Removed by application controller after app is refreshed. Value `"hard"` means manifest cache and target cluster state cache should be invalidated before refresh. | | argocd.argoproj.io/skip-reconcile | Application | `"true"` | Indicates to the Argo CD application controller that the Application should not be reconciled. See the [skip reconcile documentation](skip_reconcile.md) for use cases. | diff --git a/docs/user-guide/helm.md b/docs/user-guide/helm.md index 87d2b136d1..540f893ad7 100644 --- a/docs/user-guide/helm.md +++ b/docs/user-guide/helm.md @@ -3,7 +3,7 @@ ## Declarative You can install Helm charts through the UI, or in the declarative GitOps way. -Helm is [only used to inflate charts with `helm template`](../../faq#after-deploying-my-helm-application-with-argo-cd-i-cannot-see-it-with-helm-ls-and-other-helm-commands). The lifecycle of the application is handled by Argo CD instead of Helm. +Helm is [only used to inflate charts with `helm template`](../faq.md#after-deploying-my-helm-application-with-argo-cd-i-cannot-see-it-with-helm-ls-and-other-helm-commands). The lifecycle of the application is handled by Argo CD instead of Helm. Here is an example: ```yaml diff --git a/docs/user-guide/multiple_sources.md b/docs/user-guide/multiple_sources.md index 084aacf64a..279088f74f 100644 --- a/docs/user-guide/multiple_sources.md +++ b/docs/user-guide/multiple_sources.md @@ -37,7 +37,7 @@ the resulting manifests. > [!WARNING] > **Do not abuse multiple sources** > -> Note this feature is **NOT** destined as a generic way to group different/unrelated applications. Take a look at [applicationsets](../user-guide/application-set.md) and the [app-of-apps](../../operator-manual/cluster-bootstrapping/) pattern if you want to have a single entity for multiple applications. If you find yourself using more than 2-3 items in the `sources` array then you are almost certainly abusing this feature and you need to rethink your application grouping strategy. +> Note this feature is **NOT** destined as a generic way to group different/unrelated applications. Take a look at [applicationsets](../user-guide/application-set.md) and the [app-of-apps](../operator-manual/cluster-bootstrapping.md) pattern if you want to have a single entity for multiple applications. If you find yourself using more than 2-3 items in the `sources` array then you are almost certainly abusing this feature and you need to rethink your application grouping strategy. If multiple sources produce the same resource (same `group`, `kind`, `name`, and `namespace`), the last source to produce the resource will take precedence. Argo CD will produce a `RepeatedResourceWarning` in this case, but it will diff --git a/docs/user-guide/private-repositories.md b/docs/user-guide/private-repositories.md index 5eedbf5667..0db3a284b3 100644 --- a/docs/user-guide/private-repositories.md +++ b/docs/user-guide/private-repositories.md @@ -361,7 +361,7 @@ It is possible to add and remove TLS certificates using the ArgoCD web UI: ### Managing TLS certificates using declarative configuration You can also manage TLS certificates in a declarative, self-managed ArgoCD setup. All TLS certificates are stored in the ConfigMap object `argocd-tls-certs-cm`. -Please refer to the [Operator Manual](../../operator-manual/declarative-setup/#repositories-using-self-signed-tls-certificates-or-are-signed-by-custom-ca) for more information. +Please refer to the [Operator Manual](../operator-manual/declarative-setup.md#repositories-using-self-signed-tls-certificates-or-are-signed-by-custom-ca) for more information. ## Unknown SSH Hosts diff --git a/docs/user-guide/status-badge.md b/docs/user-guide/status-badge.md index 55d7a03484..1229425521 100644 --- a/docs/user-guide/status-badge.md +++ b/docs/user-guide/status-badge.md @@ -1,7 +1,7 @@ # Status Badge Argo CD can display a badge with health and sync status for any application. The feature is disabled by default because badge image is available to any user without authentication. -The feature can be enabled using `statusbadge.enabled` key of `argocd-cm` ConfigMap (see [argocd-cm.yaml](../operator-manual/argocd-cm-yaml/)). +The feature can be enabled using `statusbadge.enabled` key of `argocd-cm` ConfigMap (see [argocd-cm.yaml](../operator-manual/argocd-cm-yaml.md)). ![healthy and synced](../assets/status-badge-healthy-synced.png)