Create a .env file on the Viewer for every jurisdictional configuration

[emmastephenson]

What needs to be done

Add .env files for each of our pilot states:

• Tennessee
• Maine
• New Mexico
• Philadelphia

These can be kept in a separate folder called "Jurisdictional Configs" or similar.

Why it needs to be done

This will help our DevOps team when they pair with jurisdictions to ensure things are set up correctly.

Acceptance Criteria

• .env file created for each of:
• [x] Tennessee
• [x] Maine
• [x] New Mexico
• [x] Philadelphia

Technical Notes

You can refer to the Engagements Notion board to find details about each jurisdiction's setup. If you have any questions, reach out to Emma.

Additional context

Long-term, we hope to have a more robust solution for users to manage their configurations. But in the short term, this will help our DevOps team know the env vars to apply to specific jurisdictions.

[rin-skylight]

Heads up: I have concerns about this ticket. I spoke with Lina via Slack about a few of the variables...we can't necessarily enter values for everything, since Terraform generates things like connection strings at runtime. I'm also very reluctant to have any of this in publicly-accessible code, since we should theoretically have no access to these environments. By policy, we draw the support line at that stage. I would also worry that our jurisdictions may not consent to having these details anywhere open-source.

If I'm mischaracterizing this, please let me know. Otherwise, I think we need to talk over how we would want this info to be stored, and what value it brings.

[emmastephenson]

@rin-skylight finally getting back to this! None of the environment variables here are for any kind of state-specific information - it's all env vars specifically for the eCR Viewer. We won't include any sensitive information (e.g., database strings) in these sets, just variables. Effectively, we're trying to make configurations for the various ways and flavors of running the eCR Viewer - i.e., one state is running with the NBS integration and doesn't need any database variables but does need authentication enabled and the public key set up; another state is only running the non-integrated viewer so doesn't need that auth but does need a database configured, etc. I don't believe any of this data could be considered private, since it's all various ways of running the eCR Viewer. Rather the equivalent of having something like application-azure-prod.yaml over on SimpleReport - it's just the configuration that we're setting. Long-term we'd like to get to different default configurations available on the application (more like the yaml, less like a million environment variables) but this is what's needed in the short term to help out Alis and the rest of the dev team keep track of our different pilot flavors.

[rin-skylight]

@emmastephenson Again, I am going to respectfully push back on this use of environment variable files. I absolutely understand the value of having a place to store different configurations, but that place is not here. This proposed approach runs a risk of bloating into a large collection of files that are both redundant and have to be meticulously managed. I am also staunchly opposed to the storage of any deployment-specific information in code, even if it's just state-specific configurations, regardless of its sensitivity. That is something that should be in Notion or some other private area. We, as a project team, know that this data isn't "private", but it still runs a liability risk that may concern our jurisdictions. I'm not willing to take that risk.

An approach that I would support is a well-documented "master" configuration file that gives all possible environment variables, indicates the defaults and possible entries for each key, and allows users to comment and uncomment at will. That reduces overall maintenance, and it keeps our files from bloating unnecessarily. Something like this is what I have in mind: https://github.com/nextcloud/server/blob/master/config/config.sample.php (keep in mind, this is a huge file, so ours would be much smaller).