marcel/argo-cd
1
0
Fork 0
mirror of https://github.com/argoproj/argo-cd.git synced 2026-02-20 01:28:45 +01:00
Code Issues Packages Projects Releases Wiki Activity

docs: small fixes for mkdocs warnings (#26112)

Browse Source 
Signed-off-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>
Co-authored-by: Nitish Kumar <justnitish06@gmail.com>
This commit is contained in:
Michael Crenshaw
2026-01-23 08:00:47 -05:00
committed by GitHub
parent 82ee09a930
commit 65350789e8
32 changed files with 54 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
docs/developer-guide/index.md
View File

@@ -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.

4
docs/index.md
View File

@@ -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

2
docs/operator-manual/app-any-namespace.md
View File

@@ -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

2
docs/operator-manual/applicationset/Application-Deletion.md
View File

@@ -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.

8
docs/operator-manual/applicationset/Generators-Cluster.md
View File

@@ -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

2
docs/operator-manual/applicationset/Template.md
View File

@@ -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

4
docs/operator-manual/applicationset/Use-Cases.md
View File

@@ -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.

2
docs/operator-manual/cluster-bootstrapping.md
View File

@@ -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:

2
docs/operator-manual/config-management-plugins.md
View File

@@ -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 `<metadata.name>-<spec.version>`

4
docs/operator-manual/notifications/examples.md
View File

@@ -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

2
docs/operator-manual/notifications/index.md
View File

@@ -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.

2
docs/operator-manual/security.md
View File

@@ -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

4
docs/operator-manual/upgrading/1.6-1.7.md
View File

@@ -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, <your-role>, 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).

2
docs/operator-manual/upgrading/1.8-2.0.md
View File

@@ -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.

2
docs/operator-manual/upgrading/2.12-2.13.md
View File

@@ -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 |

2
docs/operator-manual/upgrading/2.14-3.0.md
View File

@@ -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

2
docs/operator-manual/upgrading/2.3-2.4.md
View File

@@ -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

2
docs/operator-manual/upgrading/3.1-3.2.md
View File

@@ -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.

2
docs/operator-manual/user-management/okta.md
View File

@@ -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

2
docs/operator-manual/web_based_terminal.md
View File

@@ -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

2
docs/operator-manual/webhook.md
View File

@@ -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

2
docs/proposals/headless-argocd.md
View File

@@ -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

2
docs/proposals/multiple-sources-for-applications.md
View File

@@ -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.

2
docs/proposals/parameterized-config-management-plugins.md
View File

@@ -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)

2
docs/proposals/proxy-extensions.md
View File

@@ -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)

4
docs/proposals/server-side-apply.md
View File

@@ -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)
---

2
docs/security_considerations.md
View File

@@ -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

4
docs/user-guide/annotations-and-labels.md
View File

@@ -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. |

2
docs/user-guide/helm.md
View File

@@ -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

2
docs/user-guide/multiple_sources.md
View File

@@ -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

2
docs/user-guide/private-repositories.md
View File

@@ -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

2
docs/user-guide/status-badge.md
View File

@@ -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)