✨ add "Manage Admin Access" features to "Settings" page

[JGreenlee]

Add interface to update admin users list via UI. Triggers the config-update workflow on the config repo to PR changes (automerge if checks pass)

Introduces env vars for GitHub App auth:
CONFIG_REPO: "e-mission/nrel-openpath-deploy-configs"
CONFIG_UPDATES_WORKFLOW: "config-update.yml"
CONFIG_UPDATES_GH_APP_PRIVATE_KEY
CONFIG_UPDATES_GH_APP_ID
CONFIG_UPDATES_GH_APP_INSTALLATION_ID

(CONFIG_REPO replaces CONFIG_PATH which was unused)

Status of the workflow and PR are monitored in the UI. If credentials aren't set, updates will fail.

Designed to support more config update actions in the future; all the functions in config_update_utils.py are generic

Testing done:
#168 (comment)

[JGreenlee]

UI shows current admins

Adding a new admin

Monitors the status of the workflow

Links to PR on success

The PR was auto merged by github actions bot because it passed the validate-configs check

After a few minutes + refresh, the new admin shows up

[JGreenlee]

For this to work on prod, we will need to provide new environment variables (CONFIG_UPDATES_GH_APP_PRIVATE_KEY, CONFIG_UPDATES_GH_APP_ID, and CONFIG_UPDATES_GH_APP_INSTALLATION_ID).
How do we currently provide secrets to containers running on prod?

I gave @TeachMeTW the necessary values to test locally against my fork and it worked as expected, with this PR being created: JGreenlee/nrel-openpath-deploy-configs#30

[shankari]

@JGreenlee on production, environment variables are configured using the AWS secrets manager. I see that you have already added them to the docker-compose 👍 You can provide them to @jgu2 and he can add them to the secrets manager before we merge + deploy

[shankari]

I looked through at a high level; I wonder if you could describe why we need get_recent_workflow_run.
when we dispatch a workflow, don't we get the workflow ID? That seems more robust than checking for recent calls - what if two deployments make changes in the same 10 minutes.
Similarly, the workflow should be able to output the ID of the PR that it creates.

[JGreenlee]

when we dispatch a workflow, don't we get the workflow ID? That seems more robust than checking for recent calls - what if two deployments make changes in the same 10 minutes.

Unfortunately no, we don't get the workflow ID. We just get an empty OK response (204)

Similarly, the workflow should be able to output the ID of the PR that it creates.

I tried this too, but there's no easy way to get an output value from a workflow run.
You can generate an artifact with the output value, or just log the output value and parse the logs on the receiving end. Either way you have to download zip files and extract them, which didn't seem worth the effort at the moment