Merge pull request #5011 from EppO/master

Charts docs clean-up
pull/5019/head
Taylor Thomas 6 years ago committed by GitHub
commit e847fa8d82
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -116,10 +116,10 @@ be deprecated. The chart name can later be reused by publishing a newer version
that is not marked as deprecated. The workflow for deprecating charts, as that is not marked as deprecated. The workflow for deprecating charts, as
followed by the [helm/charts](https://github.com/helm/charts) followed by the [helm/charts](https://github.com/helm/charts)
project is: project is:
- Update chart's `Chart.yaml` to mark the chart as deprecated, bumping the
version - Update chart's `Chart.yaml` to mark the chart as deprecated, bumping the version
- Release the new chart version in the Chart Repository - Release the new chart version in the Chart Repository
- Remove the chart from the source repository (e.g. git) - Remove the chart from the source repository (e.g. git)
## Chart LICENSE, README and NOTES ## Chart LICENSE, README and NOTES
@ -160,7 +160,6 @@ the preferred method of declaring dependencies is by using a
**Note:** The `dependencies:` section of the `Chart.yaml` from Helm **Note:** The `dependencies:` section of the `Chart.yaml` from Helm
Classic has been completely removed. Classic has been completely removed.
### Managing Dependencies with `requirements.yaml` ### Managing Dependencies with `requirements.yaml`
A `requirements.yaml` file is a simple file for listing your A `requirements.yaml` file is a simple file for listing your
@ -240,6 +239,7 @@ dependencies:
``` ```
In the above example we will get 3 dependencies in all for `parentchart` In the above example we will get 3 dependencies in all for `parentchart`
``` ```
subchart subchart
new-subchart-1 new-subchart-1
@ -283,9 +283,10 @@ dependencies:
condition: subchart2.enabled,global.subchart2.enabled condition: subchart2.enabled,global.subchart2.enabled
tags: tags:
- back-end - back-end
- subchart2 - subchart2
``` ```
```yaml ```yaml
# parentchart/values.yaml # parentchart/values.yaml
@ -294,7 +295,7 @@ subchart1:
tags: tags:
front-end: false front-end: false
back-end: true back-end: true
```` ```
In the above example all charts with the tag `front-end` would be disabled but since the In the above example all charts with the tag `front-end` would be disabled but since the
`subchart1.enabled` path evaluates to 'true' in the parent's values, the condition will override the `subchart1.enabled` path evaluates to 'true' in the parent's values, the condition will override the
@ -314,12 +315,11 @@ helm install --set tags.front-end=true --set subchart2.enabled=false
##### Tags and Condition Resolution ##### Tags and Condition Resolution
- **Conditions (when set in values) always override tags.**
* **Conditions (when set in values) always override tags.** The first condition - The first condition path that exists wins and subsequent ones for that chart are ignored.
path that exists wins and subsequent ones for that chart are ignored. - Tags are evaluated as 'if any of the chart's tags are true then enable the chart'.
* Tags are evaluated as 'if any of the chart's tags are true then enable the chart'. - Tags and conditions values must be set in the top parent's values.
* Tags and conditions values must be set in the top parent's values. - The `tags:` key in values must be a top level key. Globals and nested `tags:` tables
* The `tags:` key in values must be a top level key. Globals and nested `tags:` tables
are not currently supported. are not currently supported.
#### Importing Child Values via requirements.yaml #### Importing Child Values via requirements.yaml
@ -345,6 +345,7 @@ directly into the parent's values by specifying the keys to import as in the exa
import-values: import-values:
- data - data
``` ```
```yaml ```yaml
# child's values.yaml file # child's values.yaml file
... ...
@ -388,6 +389,7 @@ dependencies:
- child: default.data - child: default.data
parent: myimports parent: myimports
``` ```
In the above example, values found at `default.data` in the subchart1's values will be imported In the above example, values found at `default.data` in the subchart1's values will be imported
to the `myimports` key in the parent chart's values as detailed below: to the `myimports` key in the parent chart's values as detailed below:
@ -400,6 +402,7 @@ myimports:
mystring: "helm rocks!" mystring: "helm rocks!"
``` ```
```yaml ```yaml
# subchart1's values.yaml file # subchart1's values.yaml file
@ -409,6 +412,7 @@ default:
mybool: true mybool: true
``` ```
The parent chart's resulting values would be: The parent chart's resulting values would be:
```yaml ```yaml
@ -511,10 +515,10 @@ through the template engine.
Values for the templates are supplied two ways: Values for the templates are supplied two ways:
- Chart developers may supply a file called `values.yaml` inside of a - Chart developers may supply a file called `values.yaml` inside of a
chart. This file can contain default values. chart. This file can contain default values.
- Chart users may supply a YAML file that contains values. This can be - Chart users may supply a YAML file that contains values. This can be
provided on the command line with `helm install`. provided on the command line with `helm install`.
When a user supplies custom values, these values will override the When a user supplies custom values, these values will override the
values in the chart's `values.yaml` file. values in the chart's `values.yaml` file.

Loading…
Cancel
Save