Preserve keyword replacement during export

Description

Provide a clear and concise description of the issue, including what you expected to happen.

I am using the YAML version of the deploy CLI with variables replaced from a config.json. Here is an example snippet of variable usage in tenant.yaml:

...
resourceServers:
  - name: 'App ##ENVIRONMENT_NAME##'
     identifier: '##API_BASE_URL##'

I then have this config.json:

{
  ...
  "AUTH0_KEYWORD_REPLACE_MAPPINGS": {
    "ENVIRONMENT_NAME": "dev",
    "API_BASE_URL": "https://dev.myapp.com"
  }
}

When I export, variable data in tenant.yaml is overwritten with the real values. Example:

a0deploy dump --format yaml --output_folder . --config_file ./config.json

This modifies tenant.yaml with real values:

...
resourceServers:
  - name: 'App dev'
     identifier: 'https://dev.myapp.com'

Preferably this would update my config.json with the real values being exported.

Reproduction

Use environment variables in tenant.yaml or other files, these variables are incorrectly modified when exporting an Auth0 tenant.

Environment

• Version of this library used: 5.5.3
• Version of the platform or framework used, if applicable: NPM 7.6.0, Node 15.11.0
• Other relevant versions (language, server software, OS, browser): OSX
• Other modules/plugins/libraries that might be involved:

[DanoThom]

I have to say I was really scratching my head around this whole issue when first testing this flow. Since using variable substitution in the template file seems to be the ENTIRE POINT of using this tool, I just can’t understand how this hasn’t been addressed anywhere?!

At the moment it seems I have to export, and then manually diff against the file in my source control and hopefully successfully manage to move over and update anything that has changed. What’s going on here?

[willvedd]

I want to reassure everyone that this is still on our radar. We have an initiative documented and on our backlog with a tentative slotting for either this upcoming quarter or the next. Not discounting the impact of this ask, but IMO, #70 is a higher-impact feature, so that gets priority. The intention is to have this worked on almost immediately after.

Though I’d like to mention that I’m not sure if preserving variable substitutions is even possible. Sure, you could maybe implement some type of a state file, but that goes against the stateless spirit of this project. You could perform some type of lookup on resource configuration files and dynamically replace keyword values with their keys, but that could unleash a whole set of unsolvable consequences. At best, we would need to apply dynamic replacement policies on a per-resource basis, which is a decent undertaking and still may never be perfect.

All of this to say that this hasn’t been forgotten about, we’re thinking about solutions and you can expect some type of verdict sometime after #70 gets addressed.