Add local test suite to formcentral

[calufa]

Having a local environment facilitates bug fixing and feature creation.

In this PR we add infrastructure for local testing for most(?) applications contained in fly.

To try it out, execute in your terminal, ./test.sh formcentral

TODO:

• [x] Add infrastructure for local testing
• [x] Use config.go to store system-level variables and constants.
• [x] Replace "ADD" for "COPY" in Dockerfile
• [x] Create fromcentral dev environment
• [x] Move DbMaxConns to config.go
• [x] Remove testPool()
• [x] Add system service (service that resets the db)

[netlify[bot]]

✔️ Deploy Preview for vlab-research canceled.

🔨 Explore the source changes: 71fb1dd6ae49c6b2c2261bf5188ac2889791526c

🔍 Inspect the deploy log: https://app.netlify.com/sites/vlab-research/deploys/614d209fb554bb0008a970e0

[nandanrao]

@calufa - I think the main purpose here is to create a development container. I think it's a cool idea! But let's just make sure it:

• Includes a loop-on-fail structure for development experience.
• Doesn't bloat the production container for no reason.
• Provides an improved development experience than running Go locally.

[nandanrao]

One other thought: let's make sure that when we're designing a solution for containerizing the test suite, we keep in mind the design of a CI solution. We can have separate process for CI and local development, of course, but it's always nice if we could skip that overhead and have one. If we go with something like GH actions or other solutions where we get a full linux vm, docker-compose is a great solution. But if we go with something more K8s based, it's not clear to me that docker-compose would be the ideal solution for that.

[calufa]

One other thought: let's make sure that when we're designing a solution for containerizing the test suite, we keep in mind the design of a CI solution. We can have separate process for CI and local development, of course, but it's always nice if we could skip that overhead and have one.

I really like the idea, and I can definitely see a path to that.

If we go with something like GH actions or other solutions where we get a full linux vm, docker-compose is a great solution. But if we go with something more K8s based, it's not clear to me that docker-compose would be the ideal solution for that.

Let's discuss more about this, I have some thoughts I want to share with you :)

My work with the monorepo-template allows for end-to-end tests locally using only docker and docker-compose, https://github.com/calufa/monorepo-template/blob/master/infra/test.yaml.

In the monorepo-template setup, soon you will be able to run ./test.sh app_name (already works) and ./test.sh infra (WIP), where ./test.sh infra spins up kind and registry2, apps, etc., using just docker-compose.

The intention of ./test.sh infra is to be able to run end-to-end tests locally without any dependency other than docker.

...

In my mind, CI has two stages/steps for testing: 1) for running integration tests against all app 2) one for testing end-to-end using k8s

[nandanrao]

Agreed, running app tests are different from runnng e2e tests that integrate all apps! Right now, though, we're only doing the e2e tests in a CI environment.

[calufa]

Hmm, noticed 48 commits for this PR, should we squash+merge instead of just merge for this one?

[nandanrao]

@calufa - yeah could you squash and merge this?