code-corps / code-corps/code-corps-api

Refactor mix environment files so they are untethered from deployment configurations

未關閉
#991 3 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視
Difficulty: Medium Skill: Elixir Skill: Heroku
主要語言
Elixir
星號
234
分支
82
PR 合併指標
30 天內沒有已合併 PR

描述

# Problem

Per some advice from @DavidAntaramian:

> In essence, your Mix environment is not the same as a Rails environment. Very different beasts. The Mix environment should only control build concerns (like, "Should debug information be stripped from this file?") not runtime concerns. We've been bad as a community in communicating that, though.

> So, for example, the URL for the web app used in emails, that should really be stored in an environment variable. You might provide a default in the `config.exs` file, but then try and load the OS environment variable inside the application's `start/2` function and inject it into the application's Erlang environment store (`Application.put_env(:code_corps, :allowed_origins, allowed_origins)`)

> Ecto and Phoenix are trying to be better about allowing this type of thing. So Ecto has a callback on Ecto.Repo called `init/2` that you can define and use to fetch environment variables defining connection information rather than storing that in the config file (https://hexdocs.pm/ecto/Ecto.Repo.html#c:init/2). Phoenix.Endpoint has a similar `init/2` function for defining URL and HTTP transport configuration (https://hexdocs.pm/phoenix/Phoenix.Endpoint.html#c:init/2)

This is going to require:

- cleaning up the config files
- setting the new configuration on the servers, where needed
- documenting the configurations somewhere so they are not solely stored on our servers (or with any specific PaaS)

貢獻指南

開啟貢獻指南

評估

這個 Issue 還沒有評估資料。

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。