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

Refactor mix environment files so they are untethered from deployment configurations

Ouverte
#991 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub
Difficulty: Medium Skill: Elixir Skill: Heroku
Langage dominant
Elixir
Étoiles
234
Forks
82
Métriques de merge des PR
Aucune PR mergée en 30 j

Description

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

Guide de contribution

Ouvrir le guide de contribution

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.