Add support for envWithTpl

[amit-mazor]

Support envWithTpl

Add an environment variable without envWithTpl

Currently if we want to add a new environment variable, or override one, we need to specify all of the envs otherwise the rest will be override and removed.

Add an environment variable with envWithTpl

By using envWithTpl, add or change a specific environment variable, doesn't require setting all of the envs again. It allows using --set for a specific env without interrupting the other envs.

• The default 'MY_POD_IP' env is still a default env

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: amit-mazor / name: Amit Mazor (5af716bebf3e914307186ffef20b0b1ccc651500, 5f01c1ab785ef8f9a70359069379945ea784bfb0)

[amit-mazor]

@TylerHelmuth Sure, if you want to have multiple extraEnvs, but you want only one of them to be different between environments, then you currently need to copy all of the extraEnvs to all environments override files, in order to override only one env var. so for instance I have a default values.yaml where I set :

extraEnvs:
- name: app_name
  value: myTeam
- name: endpoint
  value: ireland

and then if I want per env to have the endpoint differently, then I must specify the app_name var again and again in each additional override file, altough its the same in all envs, otherwise it will be override.

by using envWithTpl , you can have a different endpoint value in each env, and keep the app_name similar in all envs, without having the need to rewrite it in every other file.

[TylerHelmuth]

@amit-mazor thanks for the explanation. I see what you're trying to accomplish, but I don't love the idea of the chart specifying 2 places where environment variables can be set. I can think of 2 ways to solve this problem:

1. Switch extraEnvs to be a dictionary instead of a list.
2. In your CI/source control maintain environment-specific values.yaml files (dev.values.yaml, prod.values.yaml, etc).

I've done option 2 in the past, but not specifically for this scenario.

If you'd like to do option 1, can you find some examples of other helm charts that use this technique?

I'm also open to other ideas, but I'm not sold on the concept of multipl env var sections in the chart.

[github-actions[bot]]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[github-actions[bot]]

Closed as inactive. Feel free to reopen if this PR is still being worked on.