feat: Support config files with viper #4558
Conversation
841a3b7 to
b44978a
Compare
kylecarbs
left a comment
There was a problem hiding this comment.
This is awesome.
Few questions:
- How do I structure objects like arrays with keys and values?
- I see we don't generate a default config right now... should we?
| "github.com/coder/coder/codersdk" | ||
| ) | ||
|
|
||
| func newConfig() codersdk.DeploymentConfig { |
There was a problem hiding this comment.
How would I structure an object array in this form?
eg.
gitauth:
- client_id: ...
- client_secret: ...
|
Oh @f0ssel there's an empty |
|
@kylecarbs look at how derp server path is configured. Basically the path for the config can use dot notation to make objects, but each field will still be a top level field in the schema. I think generating a default is not a bad idea. Where do you think something like that would live in the repo? |
|
I think a default can be done later tbh, this seems good to merge as-is so we can unblock. Just to confirm, can you manually test a few bespoke existing options to make sure that the environment variables are an exact match? I assume we're kinda hoping that Viper doesn't change anything right? |
|
@f0ssel I mean a structured array, not an object. |
Yes, I actually do think a few may change - I think this may be ok if we can document it since otherwise we'll have to manually specify overrides which gets annoying and people who know and expect the viper default will be confused. If I document a list of the changes would that work? |
|
We are gonna merge this without the structured array support to unblock other work and will make updates soon for it. |
This supports intaking settings for
coder serverfrom a config file namedserver.yamlin the--global-configdirectory. It changes the way we do flags to be config first, meaning all settings have a config value and all settings can optionally have a flag.We use viper to first set default values defined in the schema for each setting. We look for a config file if that exists and load that in, then we bind each setting to a cli flag if it's defined. Viper automatically maps to environment variables. The intake order is the following:
viper defaults from schema < values in server.yaml < coder env variable < cli flagCheckout
cli/deployment/config.gofor a view of the new deployment config schema.Net negative loc 🔥
Proposing the following breaking Changes:
CODER_INMEMORY->CODER_IN_MEMORY_DATABASEto match parity with config valuein_memory_databaseCODER_TEMPLATE_AUTOIMPORT->CODER_AUTO_IMPORT_TEMPLATES