diff --git a/docs/docs/50-user-guide/20-how-to-guides/40-working-with-stages.md b/docs/docs/50-user-guide/20-how-to-guides/40-working-with-stages.md index 86daa5eb4..0fd08945c 100644 --- a/docs/docs/50-user-guide/20-how-to-guides/40-working-with-stages.md +++ b/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`: diff --git a/docs/docs/50-user-guide/20-how-to-guides/60-verification.md b/docs/docs/50-user-guide/20-how-to-guides/60-verification.md index cc16ac7a3..d1177a070 100644 --- a/docs/docs/50-user-guide/20-how-to-guides/60-verification.md +++ b/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. diff --git a/docs/docs/50-user-guide/60-reference-docs/30-promotion-steps/git-open-pr.md b/docs/docs/50-user-guide/60-reference-docs/30-promotion-steps/git-open-pr.md index 9d29cbcb1..4ac51e138 100644 --- a/docs/docs/50-user-guide/60-reference-docs/30-promotion-steps/git-open-pr.md +++ b/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. | diff --git a/docs/docs/50-user-guide/60-reference-docs/30-promotion-steps/git-wait-for-pr.md b/docs/docs/50-user-guide/60-reference-docs/30-promotion-steps/git-wait-for-pr.md index 438452068..bd24a5d64 100644 --- a/docs/docs/50-user-guide/60-reference-docs/30-promotion-steps/git-wait-for-pr.md +++ b/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. |