helmfile: Environment filtering not working properly in v0.155.0
Operating system
macOS Ventura 13.4
Helmfile Version
0.155.0
Helm Version
3.12.1
Bug description
It seems that releases that are not included in the specified target environment gets rendered. This causes rendering to fail as referenced values in the helmfile manifest are not set in the given environment.
I would expect releases that are not targeted for the specified target environment doesn’t get rendered (as shown here in version 0.154.0). But it seems that it does in version 0.155.0.
Example helmfile.yaml
Root level (helmfile.yaml):
environments:
dev:
test:
stage:
prod:
---
helmfiles:
- path: releases/external-dns/helmfile.yaml
- path: releases/telepresence/helmfile.yaml
Sub 1 (./releases/external-dns/helmfile.yaml):
environments:
dev:
values:
- defaults.yaml
- env/dev.yaml
test:
values:
- defaults.yaml
- env/test.yaml
stage:
values:
- defaults.yaml
- env/stage.yaml
prod:
values:
- defaults.yaml
- env/prod.yaml
---
repositories:
- name: external-dns
url: https://kubernetes-sigs.github.io/external-dns/
releases:
- name: external-dns
chart: external-dns/external-dns
installed: {{.Values | get "installed" true}}
version: "1.13.0"
namespace: external-dns
values:
- sources:
- service
domainFilters:
- "sub1.{{.Values.environment}}.example.com"
- "sub2.{{.Values.environment}}.example.com"
Sub 2 (./releases/telepresence/helmfile.yaml):
environments:
dev:
values:
- defaults.yaml
- env/dev.yaml
test:
values:
- defaults.yaml
- env/test.yaml
---
repositories:
- name: datawire
url: https://app.getambassador.io
releases:
- name: traffic-manager
chart: datawire/telepresence
installed: {{.Values | get "installed" true}}
version: "2.14.0"
namespace: ambassador
values:
- clientRbac:
create: true
namespaced: true
subjects:
{{- range $k, $v := .Values.groups | fromJson }}
- kind: Group
name: {{$v.rbacGroup}}
namespace: {{$v.namespace}}
apiGroup: rbac.authorization.k8s.io
{{- end }}
client:
routing:
alsoProxySubnets: {{.Values.privateSubnets}}
Error message you’ve seen (if any)
parsing: template: stringTemplate:16:40: executing "stringTemplate" at <VALUE_PATH>: map has no entry for key "<VALUE_NAME>"
Example:
in releases/telepresence/helmfile.yaml: error during helmfile.yaml.part.1 parsing: template: stringTemplate:16:40: executing "stringTemplate" at <.Values.groups>: map has no entry for key "groups"
Steps to reproduce
https://github.com/gustavclausen/helmfile-0.155.0-bug-report
Working Helmfile Version
0.154.0
Relevant discussion
No response
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 3
- Comments: 16 (8 by maintainers)
Commits related to this issue
- Cancel rendering helmfile parts once the missing env is detected in the previous part Fixes #913 Signed-off-by: Yusuke Kuoka <ykuoka@gmail.com> — committed to helmfile/helmfile by mumoshu a year ago
- Cancel rendering helmfile parts once the missing env is detected in the previous part (#941) * Cancel rendering helmfile parts once the missing env is detected in the previous part Fixes #913 S... — committed to helmfile/helmfile by mumoshu a year ago
- Cancel rendering helmfile parts once the missing env is detected in the previous part (#941) * Cancel rendering helmfile parts once the missing env is detected in the previous part Fixes #913 S... — committed to woodcockjosh/helmfile by mumoshu a year ago
@gustavclausen @kjq @JuryA @yxxhero Thanks for your reports! This is super interesting- although the pre-0.155.0 behavior makes sense to me, apparently, the behavior has never been covered in our test.
Let me see how we can fix that. Although #885 might be the PR that introduced this breakage, the primary goal of the PR was NOT to make sub-helmfiles run even when they miss the specified environment.
Can you also confirm that, presuming we have two kinds of helmfiles, the root helmfile, and the sub-helmfiles, we can safely assume the root to always have the same or more environments than sub-helmfiles?
@mumoshu supporting
cueandjsonnetwill be a nice feature.