Merge branch 'master' into feat/cli-support-out-of-sync-only

SECURITY.md

@@ -50,7 +50,7 @@ of releasing it within a patch branch for the currently supported releases.
 
 ## Reporting a Vulnerability
 
-If you find a security related bug in ArgoCD, we kindly ask you for responsible
+If you find a security related bug in Argo CD, we kindly ask you for responsible
 disclosure and for giving us appropriate time to react, analyze and develop a
 fix to mitigate the found security vulnerability.
 

applicationset/webhook/webhook.go

@@ -19,9 +19,9 @@ import (
 	"github.com/argoproj/argo-cd/v2/pkg/apis/application/v1alpha1"
 	argosettings "github.com/argoproj/argo-cd/v2/util/settings"
 
+	"github.com/go-playground/webhooks/v6/github"
+	"github.com/go-playground/webhooks/v6/gitlab"
 	log "github.com/sirupsen/logrus"
-	"gopkg.in/go-playground/webhooks.v5/github"
-	"gopkg.in/go-playground/webhooks.v5/gitlab"
 )
 
 type WebhookHandler struct {

docs/developer-guide/releasing.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-ArgoCD is released in a 2 step automated fashion using GitHub actions. The release process takes about 60 minutes,
+Argo CD is released in a 2 step automated fashion using GitHub actions. The release process takes about 60 minutes,
 sometimes a little less, depending on the performance of GitHub Actions runners.
 
 The target release branch must already exist in the GitHub repository. If you for

docs/faq.md

@@ -139,7 +139,7 @@ See [#1482](https://github.com/argoproj/argo-cd/issues/1482).
 ## How often does Argo CD check for changes to my Git or Helm repository ?
 
 The default polling interval is 3 minutes (180 seconds). 
-You can change the setting by updating the `timeout.reconciliation` value in the [argocd-cm](https://github.com/argoproj/argo-cd/blob/2d6ce088acd4fb29271ffb6f6023dbb27594d59b/docs/operator-manual/argocd-cm.yaml#L279-L282) config map. If there are any Git changes, ArgoCD will only update applications with the [auto-sync setting](user-guide/auto_sync.md) enabled. If you set it to `0` then Argo CD will stop polling Git repositories automatically and you can only use alternative methods such as [webhooks](operator-manual/webhook.md) and/or manual syncs for deploying applications.
+You can change the setting by updating the `timeout.reconciliation` value in the [argocd-cm](https://github.com/argoproj/argo-cd/blob/2d6ce088acd4fb29271ffb6f6023dbb27594d59b/docs/operator-manual/argocd-cm.yaml#L279-L282) config map. If there are any Git changes, Argo CD will only update applications with the [auto-sync setting](user-guide/auto_sync.md) enabled. If you set it to `0` then Argo CD will stop polling Git repositories automatically and you can only use alternative methods such as [webhooks](operator-manual/webhook.md) and/or manual syncs for deploying applications.
 
 
 ## Why Are My Resource Limits `Out Of Sync`?
@@ -194,7 +194,7 @@ argocd ... --insecure
 
 ## I have configured Dex via `dex.config` in `argocd-cm`, it still says Dex is unconfigured. Why?
 
-Most likely you forgot to set the `url` in `argocd-cm` to point to your ArgoCD as well. See also
+Most likely you forgot to set the `url` in `argocd-cm` to point to your Argo CD as well. See also
 [the docs](./operator-manual/user-management/index.md#2-configure-argo-cd-for-sso).
 
 ## Why are `SealedSecret` resources reporting a `Status`?
@@ -208,14 +208,14 @@ fixed CRD if you want this feature to work at all.
 ## <a name="sealed-secret-stuck-progressing"></a>Why are resources of type `SealedSecret` stuck in the `Progressing` state?
 
 The controller of the `SealedSecret` resource may expose the status condition on resource it provisioned. Since
-version `v2.0.0` ArgoCD picks up that status condition to derive a health status for the `SealedSecret`.
+version `v2.0.0` Argo CD picks up that status condition to derive a health status for the `SealedSecret`.
 
 Versions before `v0.15.0` of the `SealedSecret` controller are affected by an issue regarding this status
 conditions updates, which is why this feature is disabled by default in these versions. Status condition updates may be
 enabled by starting the `SealedSecret` controller with the `--update-status` command line parameter or by setting
 the `SEALED_SECRETS_UPDATE_STATUS` environment variable.
 
-To disable ArgoCD from checking the status condition on `SealedSecret` resources, add the following resource
+To disable Argo CD from checking the status condition on `SealedSecret` resources, add the following resource
 customization in your `argocd-cm` ConfigMap via `resource.customizations.health.<group_kind>` key.
 
 ```yaml

docs/index.md

@@ -25,7 +25,7 @@ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/st
 ```
 
 Follow our [getting started guide](getting_started.md). Further user oriented [documentation](user-guide/)
-is provided for additional features. If you are looking to upgrade ArgoCD, see the [upgrade guide](./operator-manual/upgrading/overview.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.
 
 ## How it works

docs/operator-manual/applicationset/Generators-Pull-Request.md

@@ -232,7 +232,7 @@ spec:
 - `api`: Optional URL to access the Bitbucket REST API. For the example above, an API request would be made to `https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pullrequests`. If not set, defaults to `https://api.bitbucket.org/2.0`
 - `branchMatch`: Optional regexp filter which should match the source branch name. This is an alternative to labels which are not supported by Bitbucket server.
 
-If you want to access a private repository, ArgoCD will need credentials to access repository in Bitbucket Cloud. You can use Bitbucket App Password (generated per user, with access to whole workspace), or Bitbucket App Token (generated per repository, with access limited to repository scope only). If both App Password and App Token are defined, App Token will be used.
+If you want to access a private repository, Argo CD will need credentials to access repository in Bitbucket Cloud. You can use Bitbucket App Password (generated per user, with access to whole workspace), or Bitbucket App Token (generated per repository, with access limited to repository scope only). If both App Password and App Token are defined, App Token will be used.
 
 To use Bitbucket App Password, use `basicAuth` section.
 - `username`: The username to authenticate with. It only needs read access to the relevant repo.

docs/operator-manual/applicationset/Generators-SCM-Provider.md

@@ -318,7 +318,7 @@ Depending on whether `role` is provided in `awsCodeCommit` property, AWS IAM per
 #### Discover AWS CodeCommit Repositories in the same AWS Account as ApplicationSet Controller
 
 Without specifying `role`, ApplicationSet controller will use its own AWS identity to scan AWS CodeCommit repos.
-This is suitable when you have a simple setup that all AWS CodeCommit repos reside in the same AWS account as your ArgoCD.
+This is suitable when you have a simple setup that all AWS CodeCommit repos reside in the same AWS account as your Argo CD.
 
 As the ApplicationSet controller AWS identity is used directly for repo discovery, it must be granted below AWS permissions.
 

docs/operator-manual/ingress.md

@@ -415,9 +415,9 @@ Once we create this service, we can configure the Ingress to conditionally route
 ```
 
 ## [Istio](https://www.istio.io)
-You can put ArgoCD behind Istio using following configurations. Here we will achive both serving ArgoCD behind istio and using subpath on Istio
+You can put Argo CD behind Istio using following configurations. Here we will achive both serving Argo CD behind istio and using subpath on Istio
 
-First we need to make sure that we can run ArgoCD with subpath (ie /argocd). For this we have used install.yaml from argocd project as is
+First we need to make sure that we can run Argo CD with subpath (ie /argocd). For this we have used install.yaml from argocd project as is
 
 ```bash
 curl -kLs -o install.yaml https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
@@ -467,7 +467,7 @@ spec:
          value: "0"
 ```
 
-After that install ArgoCD  (there should be only 3 yml file defined above in current directory )
+After that install Argo CD  (there should be only 3 yml file defined above in current directory )
 
 ```bash
 kubectl apply -k ./ -n argocd --wait=true
@@ -712,15 +712,15 @@ Once the DNS change is propagated, you're ready to use Argo with your Google Clo
 
 ## Authenticating through multiple layers of authenticating reverse proxies
 
-ArgoCD endpoints may be protected by one or more reverse proxies layers, in that case, you can provide additional headers through the `argocd` CLI `--header` parameter to authenticate through those layers.
+Argo CD endpoints may be protected by one or more reverse proxies layers, in that case, you can provide additional headers through the `argocd` CLI `--header` parameter to authenticate through those layers.
 
 ```shell
 $ argocd login <host>:<port> --header 'x-token1:foo' --header 'x-token2:bar' # can be repeated multiple times
 $ argocd login <host>:<port> --header 'x-token1:foo,x-token2:bar' # headers can also be comma separated
 ```
 ## ArgoCD Server and UI Root Path (v1.5.3)
 
-ArgoCD server and UI can be configured to be available under a non-root path (e.g. `/argo-cd`).
+Argo CD server and UI can be configured to be available under a non-root path (e.g. `/argo-cd`).
 To do this, add the `--rootpath` flag into the `argocd-server` deployment command:
 
 ```yaml

docs/operator-manual/metrics.md

@@ -7,7 +7,7 @@ Metrics about applications. Scraped at the `argocd-metrics:8082/metrics` endpoin
 
 | Metric | Type | Description |
 |--------|:----:|-------------|
-| `argocd_app_info` | gauge | Information about Applications. It contains labels such as `sync_status` and `health_status` that reflect the application state in ArgoCD. |
+| `argocd_app_info` | gauge | Information about Applications. It contains labels such as `sync_status` and `health_status` that reflect the application state in Argo CD. |
 | `argocd_app_k8s_request_total` | counter | Number of kubernetes requests executed during application reconciliation |
 | `argocd_app_labels` | gauge | Argo Application labels converted to Prometheus labels. Disabled by default. See section below about how to enable it. |
 | `argocd_app_reconcile` | histogram | Application reconciliation performance. |
@@ -23,7 +23,7 @@ Metrics about applications. Scraped at the `argocd-metrics:8082/metrics` endpoin
 | `argocd_redis_request_duration` | histogram | Redis requests duration. |
 | `argocd_redis_request_total` | counter | Number of redis requests executed during application reconciliation |
 
-If you use ArgoCD with many application and project creation and deletion,
+If you use Argo CD with many application and project creation and deletion,
 the metrics page will keep in cache your application and project's history.
 If you are having issues because of a large number of metrics cardinality due
 to deleted resources, you can schedule a metrics reset to clean the
@@ -32,16 +32,16 @@ history with an application controller flag. Example:
 
 ### Exposing Application labels as Prometheus metrics
 
-There are use-cases where ArgoCD Applications contain labels that are desired to be exposed as Prometheus metrics.
+There are use-cases where Argo CD Applications contain labels that are desired to be exposed as Prometheus metrics.
 Some examples are:
 
 * Having the team name as a label to allow routing alerts to specific receivers
 * Creating dashboards broken down by business units
 
 As the Application labels are specific to each company, this feature is disabled by default. To enable it, add the
-`--metrics-application-labels` flag to the ArgoCD application controller.
+`--metrics-application-labels` flag to the Argo CD application controller.
 
-The example below will expose the ArgoCD Application labels `team-name` and `business-unit` to Prometheus:
+The example below will expose the Argo CD Application labels `team-name` and `business-unit` to Prometheus:
 
     containers:
     - command:

docs/operator-manual/security.md

@@ -173,7 +173,7 @@ kubectl edit clusterrole argocd-application-controller
 ```
 
 !!! tip
-    If you want to deny ArgoCD 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-exclusion).
 
 ## Auditing
 

docs/operator-manual/webhook.md

@@ -4,27 +4,36 @@
 
 Argo CD polls Git repositories every three minutes to detect changes to the manifests. To eliminate
 this delay from polling, the API server can be configured to receive webhook events. Argo CD supports
-Git webhook notifications from GitHub, GitLab, Bitbucket, Bitbucket Server and Gogs. The following explains how to configure
+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.
 
 !!! note
     The webhook handler does not differentiate between branch events and tag events where the branch and tag names are
     the same. A hook event for a push to branch `x` will trigger a refresh for an app pointing at the same repo with
     `targetRevision: refs/tags/x`.
 
-### 1. Create The WebHook In The Git Provider
+## 1. Create The WebHook In The Git Provider
 
 In your Git provider, navigate to the settings page where webhooks can be configured. The payload
 URL configured in the Git provider should use the `/api/webhook` endpoint of your Argo CD instance
 (e.g. `https://argocd.example.com/api/webhook`). If you wish to use a shared secret, input an
 arbitrary value in the secret. This value will be used when configuring the webhook in the next step.
 
+## Github
+
 ![Add Webhook](../assets/webhook-config.png "Add Webhook")
 
 !!! note
     When creating the webhook in GitHub, the "Content type" needs to be set to "application/json". The default value "application/x-www-form-urlencoded" is not supported by the library used to handle the hooks
 
-### 2. Configure Argo CD With The WebHook Secret (Optional)
+## Azure DevOps
+
+![Add Webhook](../assets/azure-devops-webhook-config.png "Add Webhook")
+
+Azure DevOps optionally supports securing the webhook using basic authentication. To use it, specify the username and password in the webhook configuration and configure the same username/password in `argocd-secret` Kubernetes secret in
+`webhook.azuredevops.username` and `webhook.azuredevops.password` keys.
+
+## 2. Configure Argo CD With The WebHook Secret (Optional)
 
 Configuring a webhook shared secret is optional, since Argo CD will still refresh applications
 related to the Git repository, even with unauthenticated webhook events. This is safe to do since
@@ -36,12 +45,14 @@ In the `argocd-secret` kubernetes secret, configure one of the following keys wi
 provider's webhook secret configured in step 1.
 
 | Provider        | K8s Secret Key                   |
-|-----------------| ---------------------------------|
+|-----------------|----------------------------------|
 | GitHub          | `webhook.github.secret`          |
 | GitLab          | `webhook.gitlab.secret`          |
 | BitBucket       | `webhook.bitbucket.uuid`         |
 | BitBucketServer | `webhook.bitbucketserver.secret` |
 | Gogs            | `webhook.gogs.secret`            |
+| Azure DevOps    | `webhook.azuredevops.username`   |
+|                 | `webhook.azuredevops.password`   |
 
 Edit the Argo CD kubernetes secret:
 
@@ -79,6 +90,10 @@ stringData:
 
   # gogs server webhook secret
   webhook.gogs.secret: shhhh! it's a gogs server secret
+
+  # azuredevops username and password
+  webhook.azuredevops.username: admin
+  webhook.azuredevops.password: secret-password
 ```
 
 After saving, the changes should take effect automatically.

docs/user-guide/app_deletion.md

@@ -54,7 +54,7 @@ When deleting an Application with this finalizer, the Argo CD application contro
 Adding the finalizer enables cascading deletes when implementing [the App of Apps pattern](../operator-manual/cluster-bootstrapping.md#cascading-deletion).
 
 The default propagation policy for cascading deletion is [foreground cascading deletion](https://kubernetes.io/docs/concepts/architecture/garbage-collection/#foreground-deletion).
-ArgoCD performs [background cascading deletion](https://kubernetes.io/docs/concepts/architecture/garbage-collection/#background-deletion) when `resources-finalizer.argocd.argoproj.io/background` is set.
+Argo CD performs [background cascading deletion](https://kubernetes.io/docs/concepts/architecture/garbage-collection/#background-deletion) when `resources-finalizer.argocd.argoproj.io/background` is set.
 
 When you invoke `argocd app delete` with `--cascade`, the finalizer is added automatically.
 You can set the propagation policy with `--propagation-policy <foreground|background>`.

docs/user-guide/environment-variables.md

@@ -4,6 +4,6 @@ The following environment variables can be used with `argocd` CLI:
 
 | Environment Variable | Description |
 | --- | --- |
-| `ARGOCD_SERVER` | the address of the ArgoCD server without `https://` prefix <br> (instead of specifying `--server` for every command) <br> eg. `ARGOCD_SERVER=argocd.mycompany.com` if served through an ingress with DNS |
-| `ARGOCD_AUTH_TOKEN` | the ArgoCD `apiKey` for your ArgoCD user to be able to authenticate |
+| `ARGOCD_SERVER` | the address of the Argo CD server without `https://` prefix <br> (instead of specifying `--server` for every command) <br> eg. `ARGOCD_SERVER=argocd.mycompany.com` if served through an ingress with DNS |
+| `ARGOCD_AUTH_TOKEN` | the Argo CD `apiKey` for your Argo CD user to be able to authenticate |
 | `ARGOCD_OPTS` | command-line options to pass to `argocd` CLI <br> eg. `ARGOCD_OPTS="--grpc-web"` |

docs/user-guide/external-url.md

@@ -1,6 +1,6 @@
 # Add external URL
 
-You can add additional external links to ArgoCD dashboard. For example
+You can add additional external links to Argo CD dashboard. For example
 links monitoring pages or documentation instead of just ingress hosts or other apps.
 
 ArgoCD generates a clickable links to external pages for a resource based on per resource annotation.

docs/user-guide/extra_info.md

@@ -1,6 +1,6 @@
 # Add extra Application info
 
-You can add additional information to an Application on your ArgoCD dashboard.
+You can add additional information to an Application on your Argo CD dashboard.
 If you wish to add clickable links, see [Add external URL](https://argo-cd.readthedocs.io/en/stable/user-guide/external-url/). 
 
 This is done by providing the 'info' field a key-value in your Application manifest.
@@ -21,7 +21,7 @@ info:
 ```
 ![External link](../assets/extra_info-1.png)
 
-The additional information will be visible on the ArgoCD Application details page.
+The additional information will be visible on the Argo CD Application details page.
 
 ![External link](../assets/extra_info.png)