Postgres woes

[micahflee]

After the merging of #572, there are a few issues:

Hush Line is deployed via a docker image, and the Dockerfile includes running tests to make sure everything works before generating it. Before it would run the tests using a new sqlite db, but now that we're only using postgres, that fails, and thus the docker image cannot be built: https://github.com/scidsg/hushline/actions/runs/10806155886/job/29974447684

Also, we have a dev deploy workflow: https://github.com/scidsg/hushline/blob/main/.github/workflows/dev_deploy.yml

If we add the "deploy" label to a PR, it spins up a dev environment in DigitalOcean using some terraform magic. Before, this dev environment would use a local sqlite db (since it was just temporary and we didn't care), but now we need to refactor the infra terraform code to support also spinning up a dev postgres container and using that.

[brassy-endomorph]

Test should not be run in the container as a build step. That is an anti-pattern. If you want something that tests the final artifact, you need an end-to-end test suite. It might be possible to set up pytest and flask to target a remote server (as in spin up the container pointing at postgres, run the tests against it), but I haven't seen that done before, so I'm initially doubtful.

[brassy-endomorph]

If we want a smoke test for the final container, I'd make a dir called e2e-test and put a couple of tests in using requests instead of the Flask test client. Then we run those with pytest like it's a normal test suite.

So I'd say for now yank the tests from the container. We barely have normal test coverage as it is, so removing that doesn't change much. We're also small and nimble, so quickly rolling out a patch in the even of a broken prod deploy shouldn't be an issue.

Basically, better to either yank it or commit to doing it right than some kinda shoehorn to make the tests in a RUN step work.

[micahflee]

PR to yank the tests #580