-
Notifications
You must be signed in to change notification settings - Fork 886
feat: Support config files with viper #4558
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
841a3b7
to
b44978a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This came out nice 👍
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 server
from a config file namedserver.yaml
in the--global-config
directory. 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 flag
Checkout
cli/deployment/config.go
for a view of the new deployment config schema.Net negative loc 🔥
Proposing the following breaking Changes:
CODER_INMEMORY
->CODER_IN_MEMORY_DATABASE
to match parity with config valuein_memory_database
CODER_TEMPLATE_AUTOIMPORT
->CODER_AUTO_IMPORT_TEMPLATES