Feature request: ENV var persistence

[taavo]

It would be great if ENV vars could be copied from one generation of the app to the next upon deploy. As is we have to use user provided services to hold our env vars, which isn't very nice for environments that aren't on cloud foundry (e.g. development). Hopefully this could be as simple as just fetching the ENV vars and iterating through them.

cc: @mikfreedman

[andrewlow]

There is an easy - no code changes required solution to this. You can simply specify the USER environment variables you want to persist in your manifest.yml

$ cat manifest.yml 
applications:
- services:
  - my cloudant
  disk_quota: 1024M
  host: AutoPilot
  name: AutoPilot
  command: npm start
  path: .
  domain: mybluemix.net
  instances: 1
  memory: 512M
  env:
   FOOBAR: xxxx
   BILBO: 'yyyy  yyy'

[taavo]

Correct me if I'm wrong, but wouldn't that mean you'd be keeping your env vars in source control?

[andrewlow]

It's really up to you if you want to maintain the 'production' manifest.yml in your source repository or not.

I personally do not include my production secrets in my source control, my manifest.yml contains placeholder values in source control.

Initially I was poking around the code to see what it'd take to ensure that the env vars were mapped over automatically. You can query them via the cli cf env <app name> but the output will need parsing in some manner it appears.

However, as you think thought it - having the manifest.yml be an accurate representation of the app as per the warning https://github.com/concourse/autopilot#warning it sort of makes sense that this function is not what the plugin should do for you. Otherwise it'd also query and validate the URL that the application was deployed at and ensure it was the same as that in the manifest.

[concourse-bot]

Hi there!

We use Pivotal Tracker to provide visibility into what our team is working on. A story for this issue has been automatically created.

The current status is as follows:

• #99488464 Feature request: ENV var persistence

This comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes.

[team-developer-portal]

@taavo I was expecting this behavior too. I would prefer to not specify my secret keys in my manifest file. I manage the secrets by entering them via 'cf set-env'.

[JamesMcMahon]

Tracker link no longer works. Any updates on this feature?

Seems very useful to have otherwise the user has to do things like not check their manifest into source control, which isn't great.

[mikfreedman]

I put the secrets in user provided services and then bind those to the apps in the manifest. A little bit more messing around but it works.

…

On Mon, Jan 23, 2017 at 11:41 James F McMahon ***@***.***> wrote: Tracker link no longer works. Any updates on this feature? Seems very useful to have otherwise the user has to do things like not check their manifest into source control, which isn't great. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABH0QBtIFy6jM-aHnFv5eAUWrBkrOAvoks5rVNhIgaJpZM4E-bX6> .

[JamesMcMahon]

Thanks for the work around. Still would like support for it to keep things simpler.

[zmb3]

The user provided services workaround is okay, but requires code changes to apps that consume the environment variables.

Are you willing to accept a change that persists env vars? Since this plugin is used in the Concourse cf resource, the current behavior really limits how people can use Concourse to deploy their apps.

If I have an app whose env vars are sensitive, and I want to push it from a Concourse pipeline, my options are:

1. Store these sensitive values in a manifest (which may or may not be in source control - there are drawbacks to both)
2. Move sensitive values into user provided services and update all apps that currently read env vars.
3. Don't use Concourse

I don't think any of these options are great for CF users. Is there any harm in supporting this use case?