search

bitwalker / distillery

Simplify deployments in Elixir with OTP releases!
MIT License
2.96k stars 397 forks source link

how to ignore runtime configs when using remote_console #604

Closed ghost closed 5 years ago

ghost commented 5 years ago

Steps to reproduce

When having a runtime config like with Mix.Config config provider where the system envs are required like

config :app, var: System.get_env("VAR") || raise("need VAR")

and running bin/app remote_console, it fails since the VAR env var is not set.

Is there a way to make remote_console ignore the config provider?

ghost commented 5 years ago

My current workaround: https://github.com/syfgkjasdkn/distillery-604

bitwalker commented 5 years ago

I've made a change to how commands are dispatched, both to address this issue as well as others that are related.

As of now in master, custom commands will never result in the release configs being regenerated, instead custom commands will piggy-back off the already-generated sys.config, and for those commands which need a vm.args, that will also be set.

In both cases, if configs haven't been generated yet, then neither sys.config or vm.args will be set, and any commands that require them may raise an error saying that they need them; these can also be set manually by scripts that need them via VMARGS_PATH and SYS_CONFIG_PATH

tmepple commented 5 years ago

Hi @bitwalker

This will be a breaking change for me as my custom commands (derived from your documentation) for creating the database, running migrations, etc need to run as a privileged DB user. My runtime config for DB_USER, DB_PASSWORD, etc are set by env vars which the Distillery v2.0.12 config provider properly generates into sys.config before running, then my script deletes the sys.config and vm.args files when finished. That way when the unprivileged user later runs start it generates proper sys.config and vm.args files customized for that user's env vars to boot the Phoenix app.

Is there a way to define certain custom commands as "primary" which trigger full config generation and others as "secondary" which rely on already generated config files? Is there a different way we should be doing this?