• assigned: aruni, fredm
• priority: normal
• status: closed, completed
• keywords: CI, CD, configuration, config
• type: bug

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.

This idea was mostly rejected — it seems — in favour of using external settings files that are shared with the running container and separate build scripts for the different environments. This mostly covers all the bases necessary to get the settings correct.