# Configurations ## Tags * assigned: aruni, fredm * priority: normal * status: open * keywords: CI, CD, configuration, config * type: bug ## Description There are configurations that change depending on the environment that one runs the CI/CD container. Some examples: * GN_SERVER_URL: on CI/CD it is set up as "http://cd.genenetwork.org/api3/" but this is not valid for, say, the development environments and eventually production. * SQL_URI: This can change from environment to environment * OAUTH2_CLIENT_ID: A identifier for an authorised client * OAUTH2_CLIENT_SECRET: A password the client uses to authenticate itself Some of these, e.g. `OAUTH2_CLIENT_SECRET` are sensitive data that should not be exposed to the public. ------------------------------ We could have different values for the configurations depending on the host saved, say at the top of "genenetwork-machines/genenetwork-development.scm", in some hash table or association list indexed into using the host. The values for the host can be retrieved with something like: ``` (define (hostnames-all-fqdns) "Retrieve all the hostnames defined in /etc/hosts" (sethostent) (let hnames ((hostobj (gethostent)) (thehosts (list))) (if (not (eq? hostobj #f)) (hnames (gethostent) (append thehosts (list (hostent:name hostobj)))) thehosts))) ``` and at least one of the values other than "localhost" is used to determine the configuration values to load from the storage for that host. The secrets (e.g. SECRET_KEY, OAUTH_CLIENT_ID, OAUTH_CLIENT_SECRET, etc) can be encrypted and stored in some secrets management system (e.g. Pass [https://www.passwordstore.org/] etc.) setup in each relevant host: better yet, have all configurations (secret or otherwise) encrypted and stored in such a secrets management system and fetch them from there. This reduces the mental overhead of dealing with multiple places to fetch the configs. From these, the CI/CD system can them build and intern the configurations into the store with guix functions like "plain-file", "local-file", etc.