Closed derekparker closed 8 years ago
I think it makes sense to be able to use envvars and/or cli args to specify connection settings. But I think it would be confusing for a envvar to override a config file. I would expect precedence from lowest to highest to be envvar, config file, cli arg.
Another idea would be exposing the environment in the config file in the style of Rails database.yml. Or maybe better to allow missing config file settings and only error out if they were not provided another way.
I agree on the precedence. What are your thoughts on exposing environment in config? Maybe allow config to be templated like the migrations?
As of v1.6.1 it does all of the above.
I just tagged v1.6.0. It reads PG* envvars, then config file, then command line arguments. So you can do either of the following:
PGHOST=localhost PGUSER=bob tern migrate
tern migrate --host localhost --user bob
Also, because all the required fields can now be specified outside of the tern.conf file, that file is now optional.
In addition the conf file is evaluated through text/template and the entire environment is exposed via .env.
For example:
[database]
host = {{.env.PG_PORT_5432_TCP_ADDR}}
It would be great if it was possible to override values in the config file via environment variables or flags passed to tern during invocation.
For example, given a standard tern config, override host via:
PGHOST=foo tern migrate
or
tern --pg-host=foo migrate
This is very useful for certain environments such as CI where the database could be run in a linux container that is linked into the container currently running the test suite. For example, in Docker when you link two containers it exports certain environment variables, such as
$PG_PORT_5432_TCP_ADDR
. It would be great to invoke tern like so:PGHOST=$PG_PORT_5432_TCP_ADDR tern migrate
or via the flag approach above.