Workflow for updating example screener

[prestoncabe]

Issues to overcome

• codespaces has a configurable idle timeout that I don't understand fully (apparently click around the web app isn't considered activity... )
• when the firebase emulators don't shut down gracefully, there is data loss even if you've configured them to export data when stopping.
• Codespace run through the browser is flaky in terms of using the generated proxy URLs (*-5173.app.github.dev) to test the app

Proposed MVP workflow for editing example screener)

• Open VS Code
  • make sure codespaces extension is installed
• create new codespace (from main branch)
• wait for codespace to spin up and open the web app (automatically, ~3-5 minutes)
• create a fake google account to login
• the new account should come with a copy of the latest version of the example screener
  • requires merging of @joshwanf PR Feat/account creation hook #363 before this will actually work
• make edits to the screener/custom checks.
• when finished editing, run the save example screener script (see Create way to export example screener from local emulator #396)
• make a git commit
• push
• (optional) create a new user to verify that the changes are reflected in their copy of the example screener!
• stop/delete codespace

Nice to have:

• compress save/commit/push into one step

Todo

• Work w/ Josh to merge Feat/account creation hook #363
• Test workflow myself (Preston)
• Draft documentation of the workflow
• Extra credit: augment save script to also commit and push
• Pair w/ @sierscse to test workflow with her

---

Older thoughts (before experiencing flakiness with the proxy URLs):
### Immediate ideas:

- [x] have a dedicated "tester" github account for codespace of this type (so it can be shared and therefore restarted by more than just me).
- [ ] is there a hook that can be run to do emulator export before shuthdown due to timeout?
- [ ] have a script automatically persist the data to disk at a set interval (so any data loss due to timeout or otherwise is minimal)
- [ ] share credentials

#### Other ideas:
- [ ] - set the default idle timeout for codespaces to something really long
- [ ] - more tightly manage/automate/control codespaces with github actions?

---

Longer term, might be better to just pay for a dedicated server somewhere, or, replicate the prod environment more closely (both of which would be higher effort and cost; codespaces is free from CfP)

[bdt-testing]

Made a bdt-testing gh account, seems to be an OK solution for shared codespaces... I noticed that it isn't using CfP billing... might be OK for this use-case since we are unlikely to exhaust the free tier of usage. -Preston

[prestoncabe]

Experienced lots of flakiness with running codespaces via the browser/ proxy URLs for the web app running in dev mode...

It made me rethink having (semi-)permanent testing environment and dedicated testing user for editing the example screener... proposed new "MVP" workflow above that should work with more reliability with the trade-off being slightly more complexity/waiting for the person editing the example screener (imagining @sierscse in that role at the moment).

This path also fits more with how we've imagined codespaces to this point - environments we spin up ad-hoc. Plus there is room to automate/smooth the experience over time.

[prestoncabe]

I was able to test a trivial change through the proposed workflow and succeeded!