[Feature Request] Make environment setting namespace independent

[sana-dherzog]

Can you make the einvironment setting namespace independent, so we can use the <env>-placeholder.
Unfortunatly, we have the circumstance that we have 34 productive instance there also the test productions lifes on. (historically grown)
Currently we get around by sneaky injecting the right settings after a merge to the next stage per gitlab pipeline with a bash-script.

[isc-pbarton]

This is a good use case for the Mappings Token, added in version 2.12.0:

We could do a better job of actually documenting this.

[sana-dherzog]

I tested the approach of taking the mapping token into account.
Unfortunly neither Import and Import (Force) are importing the esd file under the mapped file location.

I checked the spelling and settings. it should import the file.

Mapping Token: test
Mapping: ESD, Ens.Config.DefaultSetting, esd/<token>/

[cambot]

@sana-dherzog , why will changing your ESD mapping to esd/<env>/ not work? That provides an instance specific tokenized string for substitution.

Full disclosure: I'm not versioning default settings yet, so I don't have hands on experience beyond knowing that this module only exports deployable settings.

[sana-dherzog]

The Mapping mechanic itself is working, but we have the circumstance, that our test and prod environment are in the same instance and the setting Environment Name, to that <env> is bound to, is global and not namespace independent.

i.e. if we change this in one of our test namespaces to TEST, than on all namesapces with gsc installed the setting will change to TEST, including our prod namesapces where it has to be LIVE, because this is a system wide setting.