Feature request: No clobber of existing environment variables

[mjsqu]

When chamber is used to populate environment variables into a Elastic Container Services (ECS) task, you are able to add environment variables to the command using containerOverrides:

{
  "containerOverrides": [
    {
      "name": "string",
      "command": ["chamber","exec","<service>" ...],
      "environment": [
        {
          "name": "CLOBBERED_BY_CHAMBER",
          "value": "oops"
        }
        ...
      ]
    }
    ...
  ],
  "taskRoleArn": "string"
}

However, if you are running a chamber command these environment variables are overwritten if they exist in the service.

It would be good to be able to do:

chamber exec --noclobber <service>

And have chamber not overwrite and environment variables that are already set. An update to the way 'collisions' are handled in the code should achieve this.

To this end, --noclobber sits alongside the existing --pristine and --strict switches and should not be used with them as it works in the opposite way:

• --strict and --noclobber - Should raise an error, these switches do pretty much the opposite of each other, --strict requiring the variables be set and --noclobber telling chamber not to overwrite them
• --pristine and --noclobber - Should also error, --noclobber is allowing existing values to come through, --pristine explicitly prevents them from being inherited

[mjsqu]

Looks like this might have been already requested: #87

I have forked and am keen to work on this

[mjsqu]

Working prototype:

https://github.com/mjsqu/chamber/tree/feat/no_clobber

• Adds --noclobber and helptext
• Does not include validation against whether --strict and --pristine are set

Open to discussion here before raising a PR

[bhavanki]

I haven't been involved in this project previously beyond keeping the lights on, but would like to respond. (I'm a Segment employee.)

The no-clobber idea makes sense to me, including how it conflicts with --strict and --pristine. If you're still interested in pursuing a PR, go for it. I took a look at the branch and my only big suggestion is refactoring the LoadNoClobber func into load.

[bpottier]

Any movement here? This would be really useful for local development.