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

Refactor mix environment files so they are untethered from deployment configurations

Open
#991 3 comments 0 reactions 0 assignees View on GitHub
Difficulty: Medium Skill: Elixir Skill: Heroku
Dominant language
Elixir
Stars
234
Forks
82
PR merge metrics
No merged PRs in 30d

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)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.