feat: allow sidecars to set their own env vars and secret env - #3
Merged
Conversation
Sidecar containers could only inherit the release-wide `envVars` /
`envVarsFromSecret`, with no way to add or override anything per sidecar.
Each sidecar entry now accepts its own `envVars` (list of {name, value})
and `envVarsFromSecret` (map, rendered into a per-sidecar Secret named
`<fullname>-<sidecar>-secret-env`). Both merge on top of the release-wide
values: on a name collision the sidecar's value wins.
Two Kubernetes precedence rules make that work:
- the sidecar's secretRef is listed last in `envFrom`, and the last source
wins for duplicate keys;
- container `env` always beats `envFrom`, so a release-wide `envVars` entry
whose name the sidecar sources from its own Secret is dropped from the
rendered `env` list — otherwise it would shadow the Secret value.
Co-Authored-By: claude-flow <ruv@ruv.net>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Sidecar containers could only inherit the release-wide
envVars/envVarsFromSecret. There was no way to give a sidecar an env var of its own, or to give it a different value for one the main container already sets.Change
Each
sidecars[]entry now accepts:envVars— plain env vars, same shape as the top-level keyenvVarsFromSecret— map rendered into a per-sidecar Secret named<fullname>-<sidecar>-secret-envBoth merge on top of the release-wide values, and the sidecar's value wins on a name collision. Two Kubernetes precedence rules carry that:
secretRefis listed last inenvFrom, and for duplicate keys the last source wins;envalways beatsenvFrom— so a release-wideenvVarsentry whose name the sidecar sources from its own Secret is dropped from the renderedenvlist, otherwise it would shadow the Secret value.Sidecars with no env keys of their own render exactly as before.
Files
_deployment.yaml— sidecarenv/envFromrendering_helpers.tpl—secret-sidecar-env-nameand thesidecar.envmerge helper_secret-env.tpl+_deployment-global.tpl— per-sidecar env Secretvalues.yaml— documents the two new sidecar keys and the override ruleVerification
helm lint+helm templateon the test-template chart, output inspected for all three cases (override, sidecar-only, multiple sidecars each with their own Secret)pre-commit run --all-files— passesnpm test— 40/40 pass