Hey, is my understanding correct that for now it i...
# ask-questions
e
Hey, is my understanding correct that for now it is impossible to combine configuration of data sources, metrics etc both using GUI and
config.yml
? it's either one or the other, correct?
f
That's correct. Do you have a user case for combining them?
e
My current case: I've started a setup on my local instance, then my team created a self-hosted instance. In order to get it running quickly, I gave them my
config.yml
The next step is to enable multiple people to edit data sources, metrics and dimensions - which is not possible because of the fixed config.yml. So I'll have to first recreate everything with the GUI on the self-hosted instance to let others use GUI too
The other problem I'm seeing is that while using config.yml and locking out manual changes is good for protecting datasource settings, it makes it hard to add new metrics, which is actually one of the benefits of a GUI-based tool
So on the one hand we have the stability offered by version-controlling the config.yml, and on the other the flexibility of the GUI. For larger teams it would be great to have both somehow
f
That makes sense and I think it's doable. We can add new settings to config.yml that enables the GUI for certain parts like metrics or dimensions.
Also sounds like it might be helpful to be able to import a config.yml file from the settings page and have it auto-create all of the metrics, dimensions, and data sources in the GUI for you. We have the opposite "Export to config.yml" functionality already.
@early-tent-72446 Question for you. If you already have a config.yml with some metrics defined and you created a new metric in the GUI, would you want it to write that metric back to the config.yml file or store the new metric in the database?
e
Writing back to config.yml would be great! I'm just wondering how this could work if the config file is in an instance that is version-controlled via github. We are now running Growthbook in a container managed by K8s.