Conversation
WalkthroughThe Helm chart template for n8n deployment was modified to change how extra environment variables are rendered in the container spec. The implementation now emits simple quoted scalar values instead of supporting complex YAML structures through toYaml, eliminating flexibility for non-scalar environment variable definitions. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Tip Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@charts/n8n/templates/deployment.yaml`:
- Around line 77-80: The extraEnv rendering in templates/deployment.yaml now
forces scalar values (value: {{ $value | quote }}) which breaks valueFrom maps
and is inconsistent with worker/webhook which use toYaml; update the main
deployment's extraEnv loop to detect map vs scalar (use the same kindIs "map"
helper logic from _helpers.tpl) and when the value is a map render the full YAML
block (toYaml $value | nindent ...) to support valueFrom/secretKeyRef, otherwise
render the scalar quoted value — mirror the worker/webhook approach so all three
deployments handle complex env definitions consistently.
| {{- range $key, $value := .Values.main.extraEnv }} | ||
| - name: {{ $key }} | ||
| {{- toYaml $value | nindent 14 }} | ||
| value: {{ $value | quote }} | ||
| {{- end }} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
fd "values.yaml" --exec cat {}Repository: 8gears/n8n-helm-chart
Length of output: 22361
🏁 Script executed:
fd "deployment" -e "yaml" -e "yml" --exec grep -B 3 -A 10 "extraEnv" {}Repository: 8gears/n8n-helm-chart
Length of output: 1943
🏁 Script executed:
git log --oneline -n 20 -- "charts/n8n/templates/deployment.yaml" 2>/dev/null || echo "Git history not available"Repository: 8gears/n8n-helm-chart
Length of output: 114
🏁 Script executed:
# Check if there are any tests or examples showing extraEnv usage
find . -type f \( -name "*.md" -o -name "*.yaml" -o -name "*.yml" \) -exec grep -l "extraEnv" {} \;Repository: 8gears/n8n-helm-chart
Length of output: 295
🏁 Script executed:
grep -r "extraEnv" ./examples/Repository: 8gears/n8n-helm-chart
Length of output: 372
🏁 Script executed:
# Check if there's any documentation about kindIs function usage in Helm
grep -r "kindIs" ./charts/Repository: 8gears/n8n-helm-chart
Length of output: 139
🏁 Script executed:
# Get the full context of the current main deployment extraEnv implementation
sed -n '75,85p' ./charts/n8n/templates/deployment.yamlRepository: 8gears/n8n-helm-chart
Length of output: 547
🏁 Script executed:
# Check the worker deployment extraEnv implementation for comparison
grep -B 2 -A 5 "extraEnv" ./charts/n8n/templates/deployment.worker.yaml | head -20Repository: 8gears/n8n-helm-chart
Length of output: 459
🏁 Script executed:
grep -A 15 "extraEnv: &extraEnv" ./examples/values_full.yamlRepository: 8gears/n8n-helm-chart
Length of output: 482
🏁 Script executed:
# Check the helpers template to see the kindIs "map" usage context
grep -B 5 -A 10 'kindIs "map"' ./charts/n8n/templates/_helpers.tplRepository: 8gears/n8n-helm-chart
Length of output: 687
Fix breaks documented valueFrom support and creates inconsistency across deployments.
The change in the main deployment now only supports scalar env values (value: {{ $value | quote }}), breaking the documented pattern for environment variables that reference Kubernetes secrets or ConfigMaps via valueFrom. This exact pattern is shown in examples/values_full.yaml with DB_POSTGRESDB_PASSWORD using secretKeyRef.
Additionally, the worker and webhook deployments still use {{- toYaml $value | nindent 14 }}, which supports complex YAML structures. This creates an inconsistency where extraEnv behaves differently across the three deployment types.
The codebase already uses kindIs "map" in _helpers.tpl for similar environment variable handling, so the proposed solution is both valid and consistent with existing patterns:
Fix to support both scalar and map values
{{- range $key, $value := .Values.main.extraEnv }}
- name: {{ $key }}
- value: {{ $value | quote }}
+ {{- if kindIs "map" $value }}
+ {{- toYaml $value | nindent 14 }}
+ {{- else }}
+ value: {{ $value | quote }}
+ {{- end }}
{{- end }}This allows both simple and complex env var definitions:
extraEnv:
SIMPLE_VAR: "hello"
SECRET_VAR:
valueFrom:
secretKeyRef:
name: my-secret
key: password🤖 Prompt for AI Agents
In `@charts/n8n/templates/deployment.yaml` around lines 77 - 80, The extraEnv
rendering in templates/deployment.yaml now forces scalar values (value: {{
$value | quote }}) which breaks valueFrom maps and is inconsistent with
worker/webhook which use toYaml; update the main deployment's extraEnv loop to
detect map vs scalar (use the same kindIs "map" helper logic from _helpers.tpl)
and when the value is a map render the full YAML block (toYaml $value | nindent
...) to support valueFrom/secretKeyRef, otherwise render the scalar quoted value
— mirror the worker/webhook approach so all three deployments handle complex env
definitions consistently.
There was a problem hiding this comment.
1 issue found across 1 file
Prompt for AI agents (all issues)
Check if these issues are valid — if so, understand the root cause of each and fix them.
<file name="charts/n8n/templates/deployment.yaml">
<violation number="1" location="charts/n8n/templates/deployment.yaml:79">
P1: This fix breaks the documented `valueFrom` usage (e.g., `secretKeyRef`, `configMapKeyRef`) shown in `values.yaml`. When `$value` is a map, `{{ $value | quote }}` will render the Go map as a literal string instead of proper YAML structure. A proper fix should handle both simple scalar values and complex map values. Also, the webhook and worker deployment templates were not updated, creating inconsistent behavior.
Consider handling both cases:
```yaml
- name: {{ $key }}
{{- if kindIs "map" $value }}
{{- toYaml $value | nindent 14 }}
{{- else }}
value: {{ $value | quote }}
{{- end }}
```</violation>
</file>
Since this is your first cubic review, here's how it works:
- cubic automatically reviews your code and comments on bugs and improvements
- Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
- Add one-off context when rerunning by tagging
@cubic-dev-aiwith guidance or docs links (includingllms.txt) - Ask questions if you need clarification on any suggestion
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
| {{- range $key, $value := .Values.main.extraEnv }} | ||
| - name: {{ $key }} | ||
| {{- toYaml $value | nindent 14 }} | ||
| value: {{ $value | quote }} |
There was a problem hiding this comment.
P1: This fix breaks the documented valueFrom usage (e.g., secretKeyRef, configMapKeyRef) shown in values.yaml. When $value is a map, {{ $value | quote }} will render the Go map as a literal string instead of proper YAML structure. A proper fix should handle both simple scalar values and complex map values. Also, the webhook and worker deployment templates were not updated, creating inconsistent behavior.
Consider handling both cases:
- name: {{ $key }}
{{- if kindIs "map" $value }}
{{- toYaml $value | nindent 14 }}
{{- else }}
value: {{ $value | quote }}
{{- end }}Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At charts/n8n/templates/deployment.yaml, line 79:
<comment>This fix breaks the documented `valueFrom` usage (e.g., `secretKeyRef`, `configMapKeyRef`) shown in `values.yaml`. When `$value` is a map, `{{ $value | quote }}` will render the Go map as a literal string instead of proper YAML structure. A proper fix should handle both simple scalar values and complex map values. Also, the webhook and worker deployment templates were not updated, creating inconsistent behavior.
Consider handling both cases:
```yaml
- name: {{ $key }}
{{- if kindIs "map" $value }}
{{- toYaml $value | nindent 14 }}
{{- else }}
value: {{ $value | quote }}
{{- end }}
```</comment>
<file context>
@@ -76,7 +76,7 @@ spec:
{{- range $key, $value := .Values.main.extraEnv }}
- name: {{ $key }}
- {{- toYaml $value | nindent 14 }}
+ value: {{ $value | quote }}
{{- end }}
lifecycle:
</file context>
Which issue this PR fixes
We didn't open an issue before
During our test, we tried to install an n8n instance with Helm charts.
In the deployment, we had an extraEnv variable in the values YAML.

When we launched the helm manifest, we encounterd an error.
Error: INSTALLATION FAILED: YAML parse error on n8n/templates/deployment.yaml: error converting YAML to JSON: yaml: line 46: could not find expected ':'
After looking why, we observed that the helm chart does not write
value:before the values key in the resulting manifests.Example after launching this command in this project with the value file.
After seeing that, I updated this line on the project.
I relaunched the same command and I don't encounter the error.
By using the files made by the Helm chart fixed by our modification ti deploy n8n, the deployment works flawlessly.
Version Helm charts : 2.0.1
Checklist
Please place an 'x' in all applicable fields and remove unrelated items.
Version and Documentation
Chart.yamlfollowing semantic versioningChart.yamlif applicableartifacthub.io/changessection updated inChart.yaml(see ArtifactHub annotation reference)README.mdTesting and Validation
ah lintlocally without errorsct lint --chart-dirs charts/n8n --charts charts/n8n --validate-maintainers=false/examplesdirectorySummary by CodeRabbit