As enterprise admin I want to use my own back-end services

[brusherru]

Rationale

The enterprise admin wants to use their own auth, pm, compile, and other services. Also, it much desired to avoid rebuilding clients to update hostnames of such services. So admin should have a possibility to overwrite ENV variables like XOD_HOSTNAME via the config file.

Prerequisites

#2013 — introducing a new configuration file

User story

To overwrite a XOD_HOSTNAME variable the admin sets hostname property in the config:

{
  "hostname": "my.own.server"
}

Acceptance criteria

• the env variables should have default as it works now, but it might be overwritten by values from the config
• in the code getting some constant env variable values should be replaced with functions, which gets the value from the config file, if not specified, takes it from ENV variables set during the build process, or fallback to the default values

How to implement

1. Introduce a new property in the config.json
2. Create function getXodHostname :: void -> String with the behavior described above
3. Replace process.env.XOD_HOSTNAME and in the code with the new function

How to test

Mock the config.json file (like in #2013) and make assertions for the new function.

[nkrkv]

The env section looks weird in a config made specifically for the IDE. The fact some env variables are taken into account while bundling is an internal detail which (arguably) should not be exposed to an admin, and at such an abstract level: “place env here whatever it means”. To make an analogy it would be equivalent to requiring:

./foo-cli --env FOO_CLI_PARAM=arg

instead of

./foo-cli --param=arg

Suggest removing the abstraction, focus on a thing, and leave just plain and simple hostname