Specify which environment you wish to use with conflicting variable names

[liamawhite]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

if you have two conflicting values that you import, it would be good to be able to reference them explicitly by environment name e.g....

env1
---
values:
  somekey: value1

env2
---
values:
  somekey: value2

env3
---
imports:
  - env1
  - env2
values:
  pulumiConfig:
    value1: ${env1@somekey}
    value2: ${env2@somekey}

This problem is a little annoying when the same team controls both enviroments as you have restructure things to make them unique. But if another team owns the environment you're consuming it becomes a PITA, especially if other teams rely on the existing structure.

I'm not too bothered on the syntax its just meant to illustrate the problem!

Affected area/feature

esc

[cleverguy25]

Sorry for the delay in response. You can kind of do that today, although it might not exactly work how you expect. The feature is undocumented as we are still trying to decide how it should work before GA.

env1
---
values:
  somekey: value1

env2
---
values:
  somekey: value2

env3
---
imports:
  - env1
  - env2
values:
  pulumiConfig:
    value1: ${imports.env1.somekey}
    value2: ${imports.env2.somekey}

This is going to open to this:

{
  "pulumiConfig": {
    "value1": "value1",
    "value2": "value2"
  },
  "somekey": "value2"
}

So values.somekey is merged but the individual values are still accessible.