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

Refactor mix environment files so they are untethered from deployment configurations

Abierto
#991 3 comentarios 0 reacciones 0 asignados Ver en GitHub
Difficulty: Medium Skill: Elixir Skill: Heroku
Lenguaje dominante
Elixir
Estrellas
234
Forks
82
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

# 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)

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.