diff --git a/docs/developer-guide/api-docs.md b/docs/developer-guide/api-docs.md index b96d0c5b46a90..f9624289e3ba9 100644 --- a/docs/developer-guide/api-docs.md +++ b/docs/developer-guide/api-docs.md @@ -20,8 +20,6 @@ $ curl $ARGOCD_SERVER/api/v1/applications --cookie "argocd.token=$ARGOCD_TOKEN" {"metadata":{"selfLink":"/apis/argoproj.io/v1alpha1/namespaces/argocd/applications","resourceVersion":"37755"},"items":...} ``` -> v1.3 - Then pass using the HTTP `Authorization` header, prefixing with `Bearer `: ```bash diff --git a/docs/operator-manual/applicationset/GoTemplate.md b/docs/operator-manual/applicationset/GoTemplate.md index 3d44ac99b85fa..6d441781eb802 100644 --- a/docs/operator-manual/applicationset/GoTemplate.md +++ b/docs/operator-manual/applicationset/GoTemplate.md @@ -1,7 +1,5 @@ # Go Template -> v2.5 - ## Introduction ApplicationSet is able to use [Go Text Template](https://pkg.go.dev/text/template). To activate this feature, add diff --git a/docs/operator-manual/declarative-setup.md b/docs/operator-manual/declarative-setup.md index 4f0a57c31bc7c..6e339f58d8062 100644 --- a/docs/operator-manual/declarative-setup.md +++ b/docs/operator-manual/declarative-setup.md @@ -330,8 +330,6 @@ The following keys are valid to refer to credential secrets: ### Repositories using self-signed TLS certificates (or are signed by custom CA) -> v1.2 or later - You can manage the TLS certificates used to verify the authenticity of your repository servers in a ConfigMap object named `argocd-tls-certs-cm`. The data section should contain a map, with the repository server's hostname part (not the complete URL) as key, and the certificate(s) in PEM format as data. So, if you connect to a repository with the URL `https://server.example.com/repos/my-repo`, you should use `server.example.com` as key. The certificate data should be either the server's certificate (in case of self-signed certificate) or the certificate of the CA that was used to sign the server's certificate. You can configure multiple certificates for each server, e.g. if you are having a certificate roll-over planned. If there are no dedicated certificates configured for a repository server, the system's default trust store is used for validating the server's repository. This should be good enough for most (if not all) public Git repository services such as GitLab, GitHub and Bitbucket as well as most privately hosted sites which use certificates from well-known CAs, including Let's Encrypt certificates. diff --git a/docs/operator-manual/tls.md b/docs/operator-manual/tls.md index a9881604c1a37..3b80e765f17dd 100644 --- a/docs/operator-manual/tls.md +++ b/docs/operator-manual/tls.md @@ -113,7 +113,7 @@ for the `argocd-repo-server`, containing at least the entries for `DNS:argocd-repo-server` and `DNS:argocd-repo-server.argo-cd.svc` depending on how your workloads connect to the repository server. -## Configuring inbound TLS for argocd-dex-server > v2.5 +## Configuring inbound TLS for argocd-dex-server ### Inbound TLS options for argocd-dex-server @@ -185,7 +185,7 @@ certificate stored in the `argocd-repo-server-tls` secret. mind that when you have to replace the certificate, all workloads have to be restarted in order to properly work again. -### Configuring TLS to argocd-dex-server > v2.5 +### Configuring TLS to argocd-dex-server `argocd-server` communicates with the `argocd-dex-server` using an HTTPS API over TLS. By default, `argocd-dex-server` generates a non-persistent, self diff --git a/docs/user-guide/config-management-plugins.md b/docs/user-guide/config-management-plugins.md index a2dd91b136265..b3c6fab596763 100644 --- a/docs/user-guide/config-management-plugins.md +++ b/docs/user-guide/config-management-plugins.md @@ -163,8 +163,6 @@ CMP commands have access to 2. [Standard build environment](build-environment.md) 3. Variables in the application spec (References to system and build variables will get interpolated in the variables' values): -> v1.2 - ```yaml spec: source: @@ -179,8 +177,6 @@ spec: !!! note The `discover.command` command only has access to the above environment starting with v2.4. -> v2.4 - Before reaching the `init.command`, `generate.command`, and `discover.command` commands, Argo CD prefixes all user-supplied environment variables (#3 above) with `ARGOCD_ENV_`. This prevents users from directly setting potentially-sensitive environment variables. diff --git a/docs/user-guide/helm.md b/docs/user-guide/helm.md index b7771d10b9d43..fda56320b7b09 100644 --- a/docs/user-guide/helm.md +++ b/docs/user-guide/helm.md @@ -75,8 +75,6 @@ source: ## Helm Hooks -> v1.3 or later - Helm hooks are similar to [Argo CD hooks](resource_hooks.md). In Helm, a hook is any normal Kubernetes resource annotated with the `helm.sh/hook` annotation. @@ -142,8 +140,6 @@ argocd app set redis -p password=abc123 ## Build Environment -> v1.4 - Helm apps have access to the [standard build environment](build-environment.md) via substitution as parameters. E.g. via the CLI: @@ -177,8 +173,6 @@ It's also possible to use build environment variables for the Helm values file p ## Helm plugins -> v1.5 - Argo CD is un-opinionated on what cloud provider you use and what kind of Helm plugins you are using, that's why there are no plugins delivered with the ArgoCD image. But sometimes you want to use a custom plugin. Perhaps you would like to use Google Cloud Storage or Amazon S3 storage to save the Helm charts, for example: https://github.com/hayorov/helm-gcs where you can use `gs://` protocol for Helm chart repository access. diff --git a/docs/user-guide/jsonnet.md b/docs/user-guide/jsonnet.md index 221c0b1fa705a..699cd45335b61 100644 --- a/docs/user-guide/jsonnet.md +++ b/docs/user-guide/jsonnet.md @@ -4,8 +4,6 @@ Any file matching `*.jsonnet` in a directory app is treated as a Jsonnet file. A ## Build Environment -> v1.4 - Jsonnet apps have access to the [standard build environment](build-environment.md) via substitution into *TLAs* and *external variables*. It is also possible to add a shared library (e.g. `vendor` folder) relative to the repository root. diff --git a/docs/user-guide/private-repositories.md b/docs/user-guide/private-repositories.md index c37f29f752a04..6094a328e8cd7 100644 --- a/docs/user-guide/private-repositories.md +++ b/docs/user-guide/private-repositories.md @@ -22,8 +22,6 @@ argocd repo add https://github.com/argoproj/argocd-example-apps --username v1.2 or later - 1. Navigate to `Settings/Repositories` ![connect repo overview](../assets/repo-add-overview.png) @@ -59,8 +57,6 @@ Then, connect the repository using any non-empty string as username and the acce ### TLS Client Certificates for HTTPS repositories -> v1.2 and later - If your repository server requires you to use TLS client certificates for authentication, you can configure ArgoCD repositories to make use of them. For this purpose, `--tls-client-cert-path` and `--tls-client-cert-key-path` switches to the `argocd repo add` command can be used to specify the files on your local system containing client certificate and the corresponding key, respectively: ``` @@ -81,8 +77,6 @@ Your TLS client certificate and corresponding key can also be configured using t Private repositories that require an SSH private key have a URL that typically start with `git@` or `ssh://` rather than `https://`. -> v1.2 or later - You can configure your Git repository using SSH either using the CLI or the UI. !!! note @@ -130,12 +124,6 @@ Private repositories that are hosted on GitHub.com or GitHub Enterprise can be a !!!note Ensure your application has at least `Read-only` permissions to the `Contents` of the repository. This is the minimum requirement. -> previous to v1.9 - -GitHub App credentials are not supported. - -> v1.9 or later - You can configure access to your Git repository hosted by GitHub.com or GitHub Enterprise using the GitHub App method by either using the CLI or the UI. Using the CLI: @@ -161,12 +149,6 @@ Using the UI: ## Credential templates -> previous to v1.4 - -Credential templates are available only via declarative setup, see [Repository credentials](../../operator-manual/declarative-setup#repository-credentials) in Operator Manual. - -> v1.4 and later - You can also set up credentials to serve as templates for connecting repositories, without having to repeat credential configuration. For example, if you setup credential templates for the URL prefix `https://github.com/argoproj`, these credentials will be used for all repositories with this URL as prefix (e.g. `https://github.com/argoproj/argocd-example-apps`) that do not have their own credentials configured. To set up a credential template using the Web UI, simply fill in all relevant credential information in the __Connect repo using SSH__ or __Connect repo using HTTPS__ dialogues (as described above), but select __Save as credential template__ instead of __Connect__ to save the credential template. Be sure to only enter the prefix URL (i.e. `https://github.com/argoproj`) instead of the complete repository URL (i.e. `https://github.com/argoproj/argocd-example-apps`) in the field __Repository URL__ @@ -208,8 +190,6 @@ FATA[0000] rpc error: code = Unknown desc = authentication required ## Self-signed & Untrusted TLS Certificates -> v1.2 or later - If you are connecting a repository on a HTTPS server using a self-signed certificate, or a certificate signed by a custom Certificate Authority (CA) which are not known to ArgoCD, the repository will not be added due to security reasons. This is indicated by an error message such as `x509: certificate signed by unknown authority`. 1. You can let ArgoCD connect the repository in an insecure way, without verifying the server's certificate at all. This can be accomplished by using the `--insecure-skip-server-verification` flag when adding the repository with the `argocd` CLI utility. However, this should be done only for non-production setups, as it imposes a serious security issue through possible man-in-the-middle attacks. @@ -298,8 +278,6 @@ As a work-around, you can customize your Argo CD image. See [#1344](https://gith If you are using a privately hosted Git service over SSH, then you have the following options: -> v1.2 or later - 1. You can let ArgoCD connect the repository in an insecure way, without verifying the server's SSH host key at all. This can be accomplished by using the `--insecure-skip-server-verification` flag when adding the repository with the `argocd` CLI utility. However, this should be done only for non-production setups, as it imposes a serious security issue through possible man-in-the-middle attacks. 2. You can make the server's SSH public key known to ArgoCD by using the `cert add-ssh` command of the `argocd` CLI utility. This is the recommended method and suitable for production use. In order to do so, you will need the server's SSH public host key, in the `known_hosts` format understood by `ssh`. You can get the server's public SSH host key e.g. by using the `ssh-keyscan` utility. @@ -398,8 +376,6 @@ argocd repo add git@github.com:argoproj/argocd-example-apps.git --ssh-private-ke ## Git Submodules -> v1.4 or later - Submodules are supported and will be picked up automatically. If the submodule repository requires authentication then the credentials will need to match the credentials of the parent repository. Set ARGOCD_GIT_MODULES_ENABLED=false to disable submodule support ## Declarative Configuration diff --git a/docs/user-guide/status-badge.md b/docs/user-guide/status-badge.md index 9faba23adb3fa..8355be458f026 100644 --- a/docs/user-guide/status-badge.md +++ b/docs/user-guide/status-badge.md @@ -1,7 +1,5 @@ # Status Badge -> v1.2 - 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)).