docs: documentation for new features

docs/docs/50-user-guide/20-how-to-guides/40-working-with-stages.md

@@ -47,9 +47,17 @@ promotion to that `Stage`.
 
 When a `Stage` accepts `Freight` from one or more "upstream" `Stage` resources,
 `Freight` is considered available for promotion to that `Stage` only after being
-_verified_ in at least one of the upstream `Stage`s. Alternatively, users with
-adequate permissions may manually _approve_ `Freight` for promotion to any given
-`Stage` without requiring upstream verification.
+_verified_ in at least one of the upstream `Stage`s by default. Alternatively,
+users with adequate permissions may manually _approve_ `Freight` for promotion
+to any given `Stage` without requiring upstream verification.
+
+You can control this behavior using the `availabilityStrategy` field, which
+accepts either:
+
+- `OneOf` (default): `Freight` is available for promotion after being verified
+  in at least one of the upstream `Stage`s
+- `All`: `Freight` is available for promotion only after being verified in all
+  upstream `Stage`s listed in the `sources`
 
 :::tip
 Explicit approvals are a useful method for applying the occasional "hotfix"
@@ -98,6 +106,30 @@ spec:
   # ...
 ```
 
+In the next example, the `prod` `Stage` requests `Freight` that has originated
+from the `my-warehouse` `Warehouse`, but indicates that it will accept such
+`Freight` only after it has been _verified_ in both the `qa` and `uat`
+`Stage`s:
+
+```yaml
+apiVersion: kargo.akuity.io/v1alpha1
+kind: Stage
+metadata:
+   name: prod
+   namespace: kargo-demo
+spec:
+  requestedFreight:
+  - origin:
+      kind: Warehouse
+      name: my-warehouse
+    sources:
+      stages:
+      - qa
+      - uat
+    availabilityStrategy: All
+  # ...
+```
+
 Stages may also request `Freight` from multiple sources. The following example
 illustrates a `Stage` that requests `Freight` from both a `microservice-a` and
 `microservice-b` `Warehouse`:

docs/docs/50-user-guide/20-how-to-guides/60-verification.md

@@ -40,6 +40,25 @@ spec:
     - name: integration-test
 ```
 
+In addition to referencing `AnalysisTemplate`s, a `kind` field can be specified
+to reference [`ClusterAnalysisTemplate`s](https://argo-rollouts.readthedocs.io/en/stable/features/analysis/#clusteranalysistemplates),
+which are cluster-scoped resources that behave similarly to `AnalysisTemplate`s
+but are not namespaced:
+
+```yaml
+apiVersion: kargo.akuity.io/v1alpha1
+kind: Stage
+metadata:
+  name: dev
+  namespace: guestbook
+spec:
+  # ...
+  verification:
+    analysisTemplates:
+      - name: integration-test
+        kind: ClusterAnalysisTemplate
+```
+
 ## Configuring AnalysisTemplates
 
 An [AnalysisTemplate](../60-reference-docs/50-analysis-templates.md)
@@ -312,8 +331,3 @@ conjunction with one another.
 for a `Stage` makes it immediately available to that `Stage` _regardless_ of
 whether any required soak time has elapsed.
 :::
-
-## ClusterAnalysisTemplates
-
-Referencing `ClusterAnalysisTemplate`s is currently unsupported but is expected
-to be possible in a future release.

docs/docs/50-user-guide/60-reference-docs/30-promotion-steps/git-open-pr.md

@@ -10,15 +10,15 @@ specified source and target branches. This step is often used after a
 [`git-push` step](git-push.md) and is commonly followed by a
 [`git-wait-for-pr` step](git-wait-for-pr.md).
 
-At present, this feature only supports GitHub pull requests and GitLab merge
-requests.
+At present, this feature only supports GitHub and Gitea pull requests, and
+GitLab merge requests.
 
 ## Configuration
 
 | Name | Type | Required | Description |
 |------|------|----------|-------------|
 | `repoURL` | `string` | Y | The URL of a remote Git repository. |
-| `provider` | `string` | N | The name of the Git provider to use. Currently only `github` and `gitlab` are supported. Kargo will try to infer the provider if it is not explicitly specified.  |
+| `provider` | `string` | N | The name of the Git provider to use. Currently only `github`, `gitlab`  and `gitea` are supported. Kargo will try to infer the provider if it is not explicitly specified.  |
 | `insecureSkipTLSVerify` | `boolean` | N | Indicates whether to bypass TLS certificate verification when interfacing with the Git provider. Setting this to `true` is highly discouraged in production. |
 | `sourceBranch` | `string` | Y | Specifies the source branch for the pull request. |
 | `targetBranch` | `string` | N | The branch to which the changes should be merged. |

docs/docs/50-user-guide/60-reference-docs/30-promotion-steps/git-wait-for-pr.md

@@ -14,7 +14,7 @@ and is commonly followed by an `argocd-update` step.
 | Name | Type | Required | Description |
 |------|------|----------|-------------|
 | `repoURL` | `string` | Y | The URL of a remote Git repository. |
-| `provider` | `string` | N | The name of the Git provider to use. Currently only `github` and `gitlab` are supported. Kargo will try to infer the provider if it is not explicitly specified.  |
+| `provider` | `string` | N | The name of the Git provider to use. Currently only `github`, `gitlab` and `gitea` are supported. Kargo will try to infer the provider if it is not explicitly specified.  |
 | `insecureSkipTLSVerify` | `boolean` | N | Indicates whether to bypass TLS certificate verification when interfacing with the Git provider. Setting this to `true` is highly discouraged in production. |
 | `prNumber` | `string` | Y | The number of the pull request to wait for. |