Merge multiple secrets.yml going up

[raphink]

When using --up, it would be useful to be able to use a hierarchy of files, from most precise (local) to most generic (going up).

This would allow for example to set a token for a forge for multiple directories, by placing a secrets.yml file up in the hierarchy.

Something like this:

├── proj1
│   └── secrets.yml       # Secrets specific to proj1
├── proj2
│   └── secrets.yml       # Secrets specific to proj2
└── secrets.yml            # Generic secrets applying to both proj1 and proj2

[BradleyBoutcher]

Hi @raphink ,

Can you clarify this request a bit? I'm not sure I understand the request fully.

From what I see, this is the feature you would like:

• The addition of an --up flag
• The ability to traverse upwards and perform the summon action on a secondary yaml file found in the parent directory

[izgeri]

@raphink I wonder if this could also be resolved by just copy/pasting the common section in your project-specific secrets.yml files? I know it's not as DRY that way, but I'm not sure we want to add the capability to aggregate config from multiple secrets.yml files to this project.

You could also have a single secrets.yml for all of your projects with:

common:
  COMMON_VAR1: !var /path/to/common/var1

project1:
  PROJECT_VAR1: !var /path/to/project1/var1

project2:
  PROJECT_VAR1: !var /path/to/project2/var1

Then you can invoke it using the --environment or -e flag - if you tell it to use -e project1 it will load the project1 and common vars. If you tell it to use -e project2 it will load the project2 and common vars.

[izgeri]

@raphink I'm going to close this feature request at this time. As currently describe, I think using a single secrets.yml file with environments defined is a better solution. Please feel free to submit a new issue / reopen if you have an alternate proposal to share.