When setting cronjob.jobBackoffLimit to 0 without quotes, the rendered template contains no backoffLimit key. This is due to the check if .Values.cronjob.jobBackoffLimit interpreting 0 as false as documented here: https://pkg.go.dev/text/template#hdr-Actions
A possible workaround for the end-user is to simply quote the value, i.e.
cronjob:
jobBackoffLimit: '0'
instead of
cronjob:
jobBackoffLimit: 0
which will cause the template to render as intended. However this might not be clear for end-users.
I've attempted to fix the issue for this particular variable by changing the check to - if or (.Values.cronjob.jobBackoffLimit) (kindIs "float64" .Values.cronjob.jobBackoffLimit), i.e. checking the value as before, but also checking the kind of the value - an unquoted 0 results in a float64 kind. This feels a bit hacky though.
Any better suggestions or should this simply be left as-is?
(This could also be an issue for other keys, this is just the one I was working with at the moment)
When setting
cronjob.jobBackoffLimitto 0 without quotes, the rendered template contains nobackoffLimitkey. This is due to the checkif .Values.cronjob.jobBackoffLimitinterpreting 0 as false as documented here: https://pkg.go.dev/text/template#hdr-ActionsA possible workaround for the end-user is to simply quote the value, i.e.
instead of
which will cause the template to render as intended. However this might not be clear for end-users.
I've attempted to fix the issue for this particular variable by changing the check to
- if or (.Values.cronjob.jobBackoffLimit) (kindIs "float64" .Values.cronjob.jobBackoffLimit), i.e. checking the value as before, but also checking the kind of the value - an unquoted 0 results in a float64 kind. This feels a bit hacky though.Any better suggestions or should this simply be left as-is?
(This could also be an issue for other keys, this is just the one I was working with at the moment)