The changeset introduced via #168 assumes that podMonitor exists and its enabled property is set.
That isn't always true and if the assumption is broken, the upgrade fails.
For my case in particular, upgrade from 7.6.0 to 7.6.1 failed, but the most of the values set is rolling from at least the version 7.0.0 (I don't remember the original 6.x version with which I've started).
Error is observed as
helm upgrade --install rocketchat rocketchat/rocketchat \
--namespace rocketchat \
--description "Upgrade to 7.6.1" \
--reuse-values \
--values ./values.yaml \
--atomic --cleanup-on-fail --debug
history.go:56: 2025-05-23 22:33:17.895971961 -0300 -03 m=+0.858494816 [debug] getting history for release rocketchat
upgrade.go:164: 2025-05-23 22:33:19.534089532 -0300 -03 m=+2.496612291 [debug] preparing upgrade for rocketchat
upgrade.go:561: 2025-05-23 22:33:20.005235437 -0300 -03 m=+2.967758186 [debug] reusing the old release's values
Error: UPGRADE FAILED: template: rocketchat/templates/podmonitor.yaml:24:18: executing "rocketchat/templates/podmonitor.yaml" at <.Values.podMonitor.enabled>: nil pointer evaluating i
nterface {}.enabled
helm.go:86: 2025-05-23 22:33:21.018835059 -0300 -03 m=+3.981357806 [debug] template: rocketchat/templates/podmonitor.yaml:24:18: executing "rocketchat/templates/podmonitor.yaml" at <.
Values.podMonitor.enabled>: nil pointer evaluating interface {}.enabled
UPGRADE FAILED
main.newUpgradeCmd.func2
helm.sh/helm/v3/cmd/helm/upgrade.go:244
github.com/spf13/cobra.(*Command).execute
github.com/spf13/cobra@v1.8.1/command.go:985
github.com/spf13/cobra.(*Command).ExecuteC
github.com/spf13/cobra@v1.8.1/command.go:1117
github.com/spf13/cobra.(*Command).Execute
github.com/spf13/cobra@v1.8.1/command.go:1041
main.main
helm.sh/helm/v3/cmd/helm/helm.go:85
runtime.main
runtime/proc.go:272
runtime.goexit
runtime/asm_amd64.s:1700
with values.yaml as
image:
repository: registry.rocket.chat/rocketchat/rocket.chat
tag: 7.6.1
The changeset introduced via #168 assumes that
podMonitorexists and itsenabledproperty is set.That isn't always true and if the assumption is broken, the upgrade fails.
For my case in particular, upgrade from 7.6.0 to 7.6.1 failed, but the most of the values set is rolling from at least the version 7.0.0 (I don't remember the original 6.x version with which I've started).
Error is observed as
with values.yaml as