Skip to content

Cross-release reference

Introduced in v0.43.0

Since v0.43.0, releases are built in dependency order. This means a release can reference the already-built manifests and values of its dependencies declared in depends_on.

This enables powerful cross-release data sharing:

  • Access the entire plan configuration using getPlan. Useful for accessing the field of other releases, like tags or store.
  • Access a dependency's rendered values using getValues.
  • Access a dependency's rendered manifests using getManifests. Useful for retrieving helm-generated secrets.

How it works

graph LR redis[redis release] --> backend[backend release] redis -->|build values| redis_values[redis values] redis -->|build manifests| redis_manifests[redis manifests] redis_values -->|getValues| backend redis_manifests -->|getManifests| backend

When helmwave builds the plan:

  1. Releases are sorted by their dependency graph
  2. Each release's values are built immediately before its manifests
  3. Dependent releases can access their dependencies' built artifacts via template functions

Example

Project Structure

docs/examples/cross-release-reference
├── README.md
├── helmwave.yml
└── values
    ├── backend.yml
    └── redis.yml

2 directories, 4 files
helmwave.yml
project: "Example: cross-release reference"
version: 0.44.4

repositories:
  - name: bitnami
    url: https://charts.bitnami.com/bitnami

.options: &options
  namespace: my-namespace
  wait: watcher

releases:
  # redis is built first (no dependencies)
  - name: redis
    <<: *options
    chart: bitnami/redis
    store:
      port: 6379
    values:
      - values/redis.yml

  # backend depends on redis, so it's built after redis
  # backend's values can reference redis's built manifests and values
  - name: backend
    <<: *options
    chart: bitnami/nginx
    depends_on:
      - redis
    values:
      - values/backend.yml
values/redis.yml
connection:
  host: redis-master
  port: {{ .Release.store.port }}
values/backend.yml
# Example: Access redis's rendered values
{{ $redisValues := getValues "redis@my-namespace" "values/redis.yml" }}

# Example: Access redis's rendered manifests to get helm-generated secrets
{{ $manifests := getManifests "redis@my-namespace" }}

# Example: Access plan configuration
{{ $plan := getPlan }}

# Use data from redis release values
redis:
  host: {{ $redisValues.connection.host }}
  port: {{ $redisValues.connection.port }}

# Extract redis password from helm-generated secret
{{- range $manifests }}
{{- if eq .kind "Secret" }}
{{- if contains "redis" .metadata.name }}
  password: {{ index .data "redis-password" }}
{{- end }}
{{- end }}
{{- end }}

# Access store from plan
{{- range $plan.releases }}
{{- if eq .name "redis" }}
  store_port: {{ .store.port }}
{{- end }}
{{- end }}

Template functions

getPlan

Access the entire plan configuration, including all releases' store fields:

{{ $plan := getPlan }}
{{ range $plan.releases }}
{{- if eq .name "redis" }}
redis_port: {{ .store.port }}
{{- end }}
{{ end }}

getValues

Fetch rendered values from a depending release:

{{ $redisValues := getValues "redis@my-namespace" "values/redis.yml" }}
redis_host: {{ $redisValues.connection.host }}

getManifests

Fetch rendered manifests from a depending release as an array of Kubernetes objects. This is useful for accessing helm-generated secrets like random passwords:

{{ $manifests := getManifests "redis@my-namespace" }}
{{- range $manifests }}
{{- if eq .kind "Secret" }}
redis_password: {{ index .data "redis-password" }}
{{- end }}
{{- end }}