Problem/Motivation
I use configuration splits to manage configuration that is different between different environments of the same project. I find splits fairly stable after their initial setup i.e. they don't change frequently. I may need to change a couple of particular properties in certain configuration objects, set once, and they almost never change after that.
The workflow after that point becomes very inconvenient though. Whenever a configuration object is changed, the changes go to the patch file upon configuration export; obviously config_split does not know that I do not want the changes to go into the split. This means that every time, developers have to manually move the changes from the patch to the main configuration file.
For example, let's say a project uses a local Solr container for search, while on production it uses a cloud service. I may change the index's server property via a split, but all other index settings changed thereafter e.g. indexed fields, processor settings etc. 99% of the time will go into the main configuration object since they will be the same on all environments.
Proposed resolution
I am not sure what is the best way to improve this workflow. I was thinking to introduce the ability to "lock" a split i.e. create a new property locked: boolean. When that is set to true (defaults to false), then the configuration export does not add anything to the split. Any new changes go to the main configuration object.
Maybe that property should go to the patch, and not to the split as a whole for more flexibility, or to both i.e. the split can be locked as a whole, or the split can be unlocked but specific patches can be locked.
Once a patch is locked, a developer can still add changes directly on the file.
Is there a better solution for this?
Remaining tasks
- Agree on a solution
- Implement
User interface changes
API changes
Data model changes
