helm dependency

Manage a chart’s dependencies

Synopsis

Manage the dependencies of a chart.

Helm charts store their dependencies in ‘charts/’. For chart developers, it is often easier to manage a single dependency file (‘requirements.yaml’) which declares all dependencies.

The dependency commands operate on that file, making it easy to synchronize between the desired dependencies and the actual dependencies stored in the ‘charts/’ directory.

A ‘requirements.yaml’ file is a YAML file in which developers can declare chart dependencies, along with the location of the chart and the desired version. For example, this requirements file declares two dependencies:

  1. # requirements.yaml
  2. dependencies:
  3. - name: nginx
  4. version: "1.2.3"
  5. repository: "https://example.com/charts"
  6. - name: memcached
  7. version: "3.2.1"
  8. repository: "https://another.example.com/charts"

The ‘name’ should be the name of a chart, where that name must match the name in that chart’s ‘Chart.yaml’ file.

The ‘version’ field should contain a semantic version or version range.

The ‘repository’ URL should point to a Chart Repository. Helm expects that by appending ‘/index.yaml’ to the URL, it should be able to retrieve the chart repository’s index. Note: ‘repository’ can be an alias. The alias must start with ‘alias:’ or ‘@’.

Starting from 2.2.0, repository can be defined as the path to the directory of the dependency charts stored locally. The path should start with a prefix of “file://“. For example,

  1. # requirements.yaml
  2. dependencies:
  3. - name: nginx
  4. version: "1.2.3"
  5. repository: "file://../dependency_chart/nginx"

If the dependency chart is retrieved locally, it is not required to have the repository added to helm by “helm repo add”. Version matching is also supported for this case.

Options

  1. -h, --help help for dependency

Options inherited from parent commands

  1. --debug Enable verbose output
  2. --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm")
  3. --host string Address of Tiller. Overrides $HELM_HOST
  4. --kube-context string Name of the kubeconfig context to use
  5. --kubeconfig string Absolute path of the kubeconfig file to be used
  6. --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300)
  7. --tiller-namespace string Namespace of Tiller (default "kube-system")

SEE ALSO

Auto generated by spf13/cobra on 16-May-2019