lets add a canonical way to add new environment variables to any app via the helm `values.yaml`

[jstrachan]

so that any env vars can be added when installing a chart; or in the environment's git repository via just the values.yaml only - no need to edit the deployment YAML or anything.

We've already templated replicaCount https://github.com/jenkins-x/draft-packs/blob/master/packs/maven/charts/templates/deployment.yaml#L9 and various other things like annotations; would be nice to add an easy way to add/override env vars

[tdcox]

Yes, makes sense to standardise this since it needs to change on pretty much every app. You need to account far all the different types of environment variable declarations, which gets a bit messy if you have to insert all the boilerplate by hand each time.

[rawlingsj]

We should template most things really so it's easy to add PVs, envvars, annotations, labels etc

[tdcox]

The whole Helm experience usually ends up feeling like a bit of a hack since chart authors rarely seem to anticipate how others will need to vary from their local config.

[jstrachan]

You can do anything you want in a helm charts yaml; the issue is folks need to grok helm + the templates.

We were chatting with folks from Microsoft around this; I think longer term we'll try add all the data folks can configure (env vars, labels, annotations and stuff) to values.yaml so that a typical user doesn't have to grok the templating inside the charts/foo/templates/*.yaml files & they can just focus on values.yaml - then its more like the application.yml in spring boot (and so that folks don't have to grok all the classes and annotations in the spring boot world).

Also VS Code is increasingly capable of defaulting those values (e.g. there was an awesome demo of VS Code updating the helm chart for service catalog bindings at KubeCon). So longer term hopefully CLI + IDEs can automate much of the configuration of the helm charts (e.g. to enable debug) via just values.yaml - to simplify the developer experience

[jstrachan]

I'd also like to have wizards, say, in VS Code to add env vars, volumes, secrets and whatnot

[vochicong]

Have you considered https://github.com/kubernetes-sigs/kustomize ? It uses "normal" yaml to override variant settings.

[iamonkara]

Any updates on this ? I need something similar/same https://github.com/jenkins-x/jx/issues/1667

[jstrachan]

@iamonkara today its a case of manually modifying your local charts/myapp/templates/deployment.yaml and adding to the env: section - we just don't have a simple CLI to automate this - am hoping for a nice VS Code addon to do this kinda thing (ditto for adding a volume/secret etc)

[iamonkara]

@jstrachan I tried your suggestion to use the env specific settings from env repos but not succeeding

in my test environment repo the values.yaml has

env:
  rails: test
  extra_setting: "should be in test"

in my app charts/myapp/values.yaml i have

env:
  rails: development
  extra_setting: "I am in development"

and in charts/myapp/deployment.yaml I have

        env:
          - name: RAILS_ENV
            value: {{ .Values.env.rails | default "development" }}
          - name: EXTRA_SETTING
            value: {{ .Values.env.extra_setting | default "should be in development" }}

but when the app runs in test environment the value for RAILS_ENV is development and EXTRA_SETTING is I am in development which is wrong. The expected values are RAILS_ENV is test and EXTRA_SETTING is should be in test

Any help in debugging this?

[jenkins-x-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close. Provide feedback via https://jenkins-x.io/community. /lifecycle stale

[jenkins-x-bot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with /close. Provide feedback via https://jenkins-x.io/community. /lifecycle rotten

[jenkins-x-bot]

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten. Provide feedback via https://jenkins-x.io/community. /close

[jenkins-x-bot]

@jenkins-x-bot: Closing this issue.

In response to [this](https://github.com/jenkins-x/jx/issues/812#issuecomment-517886229): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. >Provide feedback via https://jenkins-x.io/community. >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.