Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit62c3b36

Browse files
authored
Gitops promotions round2 (#1092)
* Update after review* Update after review* Update after review* Update after review* Update after review* Add topic for getting started* Add submenu for promotion scenariosCollated promotion scenarios in bucket* Add submenu for promotion scenariosCollated promotion scenarios in bucket* Add submenu for promotion scenariosCollated promotion scenarios in bucket* Add submenu for promotion scenariosCollated promotion scenarios in bucket* Fix links* Change titles for promotion scenario and sequence articlesChanged titles to Promotion tutorials and and Promotion End-to end* Change title of policy tutorial* Add YAML spec examples* Add links to YAML specsAdded section on CRDs and links to YAML specs* Update promotion-components.md* Updates* Update promotion-components.md
1 parentd566ccf commit62c3b36

15 files changed

+341
-17
lines changed

‎_data/nav.yml‎

Lines changed: 12 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -408,7 +408,7 @@
408408
url:"/drag-and-drop"
409409
-title:Multi-environment sequential promotion
410410
url:"/multi-env-sequential-flow"
411-
-title:Policy driven multi-environment promotion
411+
-title:Multi-environment promotion with conditions
412412
url:"/policy-multi-env-promotion"
413413
-title:Multi-environment promotion with parallel environments
414414
url:"/parallel-multi-env-promotion"
@@ -423,6 +423,17 @@
423423
url:"/promotion-policy"
424424
-title:Promotion Workflows
425425
url:"/promotion-workflow"
426+
-title:YAML specs
427+
url:"/yaml"
428+
sub-pages:
429+
-title:Product YAML
430+
url:"/product-crd"
431+
-title:Promotion Template YAML
432+
url:"/promotion-template-crd"
433+
-title:Promotion Flow YAML
434+
url:"/promotion-flow-crd"
435+
-title:Promotion Policy YAML
436+
url:"/promotion-policy-crd"
426437
-title:Trigger promotions
427438
url:"/trigger-promotions"
428439
-title:Tracking releases for products

‎_docs/products/configure-product-settings.md‎

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -28,15 +28,15 @@ This article describes how to configure the different Product Settings:
2828

2929

3030

31-
#####Form & YAML modes
31+
##Form & YAML modes
3232
As with most GitOps entities, you have the option to configure Product Settings in Form or YAML modes, and switch seamlessly between them during configuration.
3333

34-
No matter what mode you use to configure Product Settings, all settings, except applications manually assigned to the product are saved in the product resource CRD in the Shared Configuration Repository in`<shared-config-repo>/resources/configuration/products/<product-name>.crd`.
35-
Applications manually assigned to the product are saved locally and not as part of the product's definitions.
36-
37-
34+
No matter what mode you use to configure Product Settings, all settings, except applications manually assigned to the product are saved as a CRD (Custom Resource Definition) within the Shared Configuration Repository in the GitOps Runtime selected as the Configuration Runtime.
35+
The path in the Shared Configuration Repo is`<gitops-runtime>/<shared-configuration-repo>/resources/configurations/products/<product-name>.crd`.
3836

37+
See[Shared Configuration Repository]({{site.baseurl}}/docs/installation/gitops/shared-configuration/) and[Designating Configuration Runtimes]({{site.baseurl}}/docs/installation/gitops/monitor-manage-runtimes/#designating-configuration-runtimes).
3938

39+
For the YAML specifications, see[Product YAML]({{site.baseurl}}/docs/promotions/configuration/yaml/product-crd/) and[Promotion Template YAML({{site.baseurl}}/docs/promotions/configuration/yaml/promotion-template-crd/).
4040

4141

4242

‎_docs/promotions/configuration.md‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -10,3 +10,5 @@ Configure the specialized promotion entities:
1010
*[Promotion Flows]({{site.baseurl}}/docs/promotions/configuration/promotion-flow/) (only account admins)
1111
*[Promotion Policies]({{site.baseurl}}/docs/promotions/configuration/promotion-policy/) (only account admins)
1212
*[Promotion Workflows]({{site.baseurl}}/docs/promotions/configuration/promotion-workflow/)
13+
14+
If you are more comfortable with YAML, see our[YAML specfication examples]({{site.baseurl}}/docs/promotions/configuration/yaml/) for the same.

‎_docs/promotions/configuration/promotion-flow.md‎

Lines changed: 9 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -27,11 +27,17 @@ Review [key insights](#promotion-flow-behavior-key-insights) to understand promo
2727

2828

2929

30-
##Flow Builder vs. YAML
31-
You can create Promotion Workflows through the Flow Builder, a graphical interface, or through a YAML Custom Resource Definition (CRD). You can switch seamlessly between both when creating Promotion Flows.
3230

31+
32+
33+
##Flow Builder vs. YAML
34+
You can create Promotion Workflows through the Flow Builder, a graphical interface, or through a YAML Custom Resource Definition (CRD).
3335
The Flow Builder visually guides you through creating any type of Promotion Flow. See[Create a Promotion Flow](#create-a-promotion-flow).
34-
<!-- For a description of the CRD definition, see TBD-->
36+
37+
Once configured and committed, Promotion Flow settings are saved as a CRD (Custom Resource Definition) within the Shared Configuration Repository in the GitOps Runtime selected as the Configuration Runtime.
38+
The path in the Shared Configuration Repo is`<gitops-runtime>/<shared-configuration-repo>/resources/configurations/promotion-flows`.
39+
See[Shared Configuration Repository]({{site.baseurl}}/docs/installation/gitops/shared-configuration/) and[Designating Configuration Runtimes]({{site.baseurl}}/docs/installation/gitops/monitor-manage-runtimes/#designating-configuration-runtimes).
40+
3541

3642

3743
##Sequential vs. parallel promotions

‎_docs/promotions/configuration/promotion-policy.md‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -40,7 +40,12 @@ The logic for applying Promotion Policy settings is based on predefined prioriti
4040
[Promotion Policy implementation logic](#promotion-policy-implementation-logic) details different scenarios and examples describing the implementation logic.
4141

4242

43+
##Promotion Policy YAML
44+
Once configured and committed, Promotion Policy settings are saved as a CRD (Custom Resource Definition) within the Shared Configuration Repository in the GitOps Runtime selected as the Configuration Runtime.
45+
The path in the Shared Configuration Repo is`<gitops-runtime>/<shared-configuration-repo>/resources/configurations/promotion-policies/`.
46+
See[Shared Configuration Repository]({{site.baseurl}}/docs/installation/gitops/shared-configuration/) and[Designating Configuration Runtimes]({{site.baseurl}}/docs/installation/gitops/monitor-manage-runtimes/#designating-configuration-runtimes).
4347

48+
For the YAML specifications, see[Promotion Policy YAML]({{site.baseurl}}/_docs/promotions/configuration/yaml/promotion-policy-crd/).
4449

4550

4651

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
---
2+
title:"YAML specs"
3+
description:"YAML specifications for promotion entities"
4+
group:promotions
5+
toc:true
6+
---
7+
8+
Codefresh provides two options for defining manifests for promotion entities: Form mode and YAML mode.
9+
10+
If you prefer working with YAML, create manifests for promotion entities using our YAML examples:
11+
*[Product YAML]({{site.baseurl}}/docs/promotions/configuration/yaml/product-crd/)
12+
*[Promotion Template YAML]({{site.baseurl}}/docs/promotions/configuration/yaml/promotion-template-crd/)
13+
*[Promotion Flow YAML]({{site.baseurl}}/docs/promotions/configuration/yaml/promotion-flow-crd/)
14+
*[Promotion Policy YAML]({{site.baseurl}}/docs/promotions/configuration/yaml/promotion-policy-crd/)
Lines changed: 87 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
---
2+
title:"Product YAML"
3+
description:"YAML specifications for the product defining its promotion and flow settings"
4+
group:promotions
5+
toc:true
6+
---
7+
8+
9+
Codefresh provides two options for defining manifests for promotion entities: Form mode and YAML mode.
10+
11+
If you prefer working with YAML, create the manifest for the product settings using the example Product YAML below, and the table with field descriptions.
12+
13+
Once configured and committed, the settings are saved as a Custom Resource Definition (CRD) within the Shared Configuration Repository in the GitOps Runtime specified as the Configuration Runtime.
14+
15+
16+
17+
##Product YAML example
18+
Here's an example of the Product YAML. The table that follows describes the fields in the Product YAML.
19+
20+
21+
```yaml
22+
apiVersion:codefresh.io/v1beta1
23+
kind:Product
24+
metadata:
25+
name:helm-guestbook#name of product
26+
spec:
27+
promotionTemplateRef:gs-promotion-template#reference to predefined promotion template; optional if using inline template
28+
promotionTemplate:# custom inline promotion template; optional if using predefined promotion template
29+
versionSource:
30+
file:version.yaml
31+
jsonPath:$.appVersionInline
32+
promotion:
33+
Chart.yaml:
34+
jsonPaths:
35+
-$.appVersion
36+
-$.version
37+
-$.dependencies
38+
version.yaml:
39+
jsonPaths:
40+
-$.appVersionInline
41+
values.yaml:
42+
jsonPaths:
43+
-$..image
44+
requirements.yaml:
45+
jsonPaths:
46+
-"$.dependencies"
47+
promotionFlows:# orchestration flow to promote product across environments; first flow that matches gitTriggerSelectors is selected
48+
-name:to-prod
49+
gitTriggerSelectors:
50+
-key:commitMessage
51+
operator:In
52+
values:
53+
-"*deploy*"
54+
-name:demo
55+
gitTriggerSelectors:
56+
-key:gitRevision
57+
operator:In
58+
values:
59+
-"hotfix"
60+
```
61+
62+
63+
## Product YAMl field descriptions
64+
65+
66+
| Field | Description | Type | Required/Optional |
67+
|-------|-------------|------|-------------------|
68+
|`metadata.name` | The name of the product resource, which must conform to the naming conventions for Kubernetes resources.<br>The name unifies all the applications connected to this product and is displayed in the Products dashboard.<br>For example, `helm-guestbook`. |string | Required |
69+
| `spec.promotionTemplateRef` | The predefined Promotion Template according to which the properties in the product's applications are selected to be promoted across environments.<br>Required if `spec.promotionTemplate` is not defined.<br>When a predefined Promotion Template is defined, both the version of the release, and the specific files and attributes to be promoted across environments are taken from the Promotion Template. |string | Optional |
70+
| `spec.promotionTemplate` | The custom inline Promotion Template according to which the properties in the product's applications are selected to be promoted across environments.<br>Required if `spec.promotionTemplateRef` is not defined.| string |Optional |
71+
| `spec.promotionTemplate.versionSource` | The location of the file and the attribute from which to extract the product's application release version. This is the version displayed in the Products and Environments dashboards.| |Optional |
72+
| `spec.promotionTemplate.versionSource.file` | The file path relative to the application's file path from which to extract the application's release version. For example, `chart.yaml` indicates that the release version should be extracted from this file.| string | Required |
73+
| `spec.promotionTemplate.versionSource.jsonPath` | The JSON path expression pointing to the location of the attribute containing the application version within the specified `file`.<br>For example, `$.appVersion` indicates the value should be extracted from the field `appVersion` in `chart.yaml`.| string| Required |
74+
|`spec.promotion`| The top-level element defining the specific changes to be promoted to the target environment, through a single or a list of `<filename>:jsonPaths`.<br>`jsonPaths` can define the path to single or multiple attributes within the same file. <br>When omitted, *all* changes in *all* applications connected to the Product are promoted.<br> Examples:<br>Extract `name` attribute from `chart.yaml` at `JSON path:$.name`<br>Extract all properties of the `dependencies` object from `chart.yaml` at `JSON path: $..dependencies.*`<br>Extract the `repository` property from the `image` object in `values.yaml` at `JSON path: $..image.repository` |array | Optional |
75+
| `spec.promotion.filename` | The file path relative to the application's file path from which to select properties to promote. | string | Optional |
76+
| `spec.promotion.jsonPath` | The JSON path expression pointing to the location of the attribute with the value to be promoted within the specified `filename`.<br>For example, `$.appVersion` indicates the value should be extracted from the field `appVersion` in `chart.yaml`.| string| Optional |
77+
| `spec.promotionFlows` | The top-level element defining one or more Promotion Flows to orchestrate the product's promotion from the trigger environment, across all target environments and up to the final target environment.<br>When there is more than one Promotion Flow, the first one in the list that matches the `gitTriggerSelector` is executed. | - | Optional |
78+
|`spec.promotionFlows.name` | The name of the Promotion Flow to execute.| string | Required|
79+
| `spec.promotionFlows.gitTriggerSelectors` |The criteria or conditions to trigger the Promotion Flow, evaluated according to the payload from the application's Git repository.<br>You can have more than one `gitTriggerSelector` for the same Promotion Flow. In such cases, the conditions are matched according to the `key`, `operator`, and `values` fields.<br>Examples:<br>With commit message<br>`key:commitMessage` `operator: In` `values: - "*deploy*" - "*release*"`<br>This selector checks if the `commitMessage` includes either "deploy" or "release" using wildcards for partial matches.<br>With Git revision (commit hash) message<br>`key: gitRevision` `operator: NotIn` `values: - "a1b2c3d4" - "e5f6g7h8"`<br>This selector checks if the `gitRevision` matches exactly either "a1b2c3d4" or "e5f6g7h8".| string |Required |
80+
| `spec.promotionFlows.gitTriggerSelectors.key` | The specific attribute from the Git payload to evaluate, and can be one of the following:{::nomarkdown}<ul><li><code class="highlighter-rouge">commitMessage</code>:Trigger the Promotion Flow based on the text description associated with the commit message. The commit message is matched against the values provided.</li><li><code class="highlighter-rouge">gitRevision</code>: Trigger the Promotion Flow based on the commit hash generated by Git as a unique identifier for the commit. The commit hash is matched against the values provided.</li></ul>{:/} | string | Required |
81+
|`spec.promotionFlows.gitTriggerSelectors.operator` | The operator to apply when matching the `gitTriggerSelectors.key`, and can be one of the following:{::nomarkdown}<ul><li><code class="highlighter-rouge">In</code>:Checks if the commit message or Git revision <i>includes</i> the specified value or any value within a set of values. The <code class="highlighter-rouge">In</code> operator matches values by exact match, or by partial match when asterisks are used as wildcards.</li><li><code class="highlighter-rouge">NotIn</code>: Checks if the commit message or Git revision <i>does not include</i> the specified value or any value within a set of values. Useful for excluding resources that match any value within a predefined list.<br>The <code class="highlighter-rouge">NotIn</code> operator matches values by exact match, or by partial match when asterisks are used as wildcards.</li></ul></li>{:/} |string |Required |
82+
|`spec.promotionFlows.gitTriggerSelectors.values` |Single or list of comma-separated values used to match or exclude Promotion Flows based on criteria defined by `gitTriggerSelectors.operator`. The values can be strings, numbers, or other data types depending on the context.|array |Required |
83+
84+
## Related articles
85+
[Promotion Policy YAML]({{site.baseurl}}/docs/promotions/promotion-policy-crd/)
86+
[Promotion Template YAML]({{site.baseurl}}/docs/promotions/promotion-template-crd/)
87+
[Promotion Flow YAML]({{site.baseurl}}/docs/promotions/promotion-flow-crd/)
Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
---
2+
title:"Promotion Flow YAML"
3+
description:"YAML specifications for defining the orchestration flow for product promotion"
4+
group:promotions
5+
toc:true
6+
---
7+
8+
9+
Codefresh provides two options for defining manifests for promotion entities: Form mode and YAML mode.
10+
11+
If you prefer working with YAML, create the manifest using the example Promotion Flow YAML below, and the table with field descriptions.
12+
13+
Once configured and committed, the settings are saved as a Custom Resource Definition (CRD) within the Shared Configuration Repository in the GitOps Runtime specified as the Configuration Runtime.
14+
15+
##Promotion Flow YAML example
16+
Here's an example of the Promotion Flow manifest. The table that follows describes the fields in the Promotion Flow manifest.
17+
18+
```yaml
19+
apiVersion:codefresh.io/v1beta1
20+
kind:PromotionFlow
21+
metadata:
22+
name:global-parallel-flow
23+
spec:
24+
properties:
25+
triggerEnvironment:dev# name of the initial environment that triggers promotion flow
26+
steps:# one or more environments across which to promote product
27+
-environment:qa# target environment
28+
dependsOn:# environment to successfully promote before triggering promotion for target
29+
-dev
30+
-environment:staging
31+
dependsOn:
32+
-qa
33+
policy:
34+
preAction:pre-action# optional; the promotion workflow to run before the promotion action
35+
postAction:post-action# optional; the promotion workflow to run after the promotion action
36+
action:commit# required; the promotion action to execute
37+
-environment:production
38+
dependsOn:
39+
-staging
40+
```
41+
42+
## Promotion Flow YAML field descriptions
43+
44+
{: .table .table-bordered .table-hover}
45+
| Field | Description | Type | Required/Default |
46+
|----------------------|---------------------------------------------------------------- |--------|------------------|
47+
|`metadata.name` | The name of the Promotion Policy, which must conform to the naming conventions for Kubernetes resources. Useful if the name indicates the purpose of this Promotion Policy - where and how it is intended to be used. For example, `productionDeployments`. | string | Required |
48+
|`spec.steps` | The step in the Promotion Flow that defines the list of target environments and their dependencies. <br>At least one target environment and dependency must be defined. | array | Required |
49+
|`spec.steps.environment` | The name of the specific target environment for which to trigger the promotion. | string | Required |
50+
|`spec.steps.environment.dependsOn`| One or more environments that must be successfully promoted before promotion can be triggered in the succeeding environments. | array | Required |
51+
|`spec.steps.policy`| The Pre-Action Workflow, Action, and Post-Action Workflow to implement for the Promotion Policy through the `action`, `preAction`, and `postAction` attributes. <br>The Action attribute is required.<br>An `policy` attribute defined here overrides global Policies that match the product/environment. See [Promotion Policy implementation logic]({{site.baseurl}}/docs/promotions/promotion-policy/#promotion-policy-implementation-logic) for information on how they are applied. | object | Optional |
52+
| `spec.steps.policy.action` | The action that should trigger the promotion in the target environment for this Promotion Policy.<br>Can be one of the following:{::nomarkdown}<ul><li><code class="highlighter-rouge">commit</code>:Executes a commit operation on the target application.</li><li><code class="highlighter-rouge">pr</code>: Executes a commit and opens a pull request for the target application.<br>Useful when you need manual approval before commit.</li><li><code class="highlighter-rouge">none</code>: Does not execute any action on the target application.<br>In this case, the Post-Action workflow must include a step that is equivalent </li></ul>{:/}| string | Required |
53+
| `spec.steps.policy.preAction` | The name of the Promotion Workflow to execute _before_ `spec.steps.policy.action`. | string | Optional |
54+
| `spec.steps.policy.postAction` | The name of the Promotion Workflow to execute after `spec.steps.policy.action`. | string | Optional |
55+
56+
## Related articles
57+
[Product CRD]({{site.baseurl}}/docs/promotions/product-crd/)
58+
[Promotion Template YAML]({{site.baseurl}}/docs/promotions/promotion-template-crd/)
59+
[Promotion Policy YAML]({{site.baseurl}}/docs/promotions/promotion-policy-crd/)

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp