Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use separate docker-compose projects for tests and local dev databases #1690

Closed
yusefnapora opened this issue Mar 22, 2022 · 4 comments
Closed
Assignees
Labels
effort/hours Estimated to take one or several hours kind/enhancement A net-new feature or improvement to an existing feature kind/maintenance Work required to avoid breaking changes or harm to project's status quo pi/support-0 status/ready Ready to be worked topic/devexp Developer Experience

Comments

@yusefnapora
Copy link
Contributor

The current docker-compose setup for testing and local development supports two use cases that have a lot of overlapping functionality: running unit / integration tests, and manually poking at things during iterative development.

The first use case wants a clean slate for each run, while the second benefits from a persistent data store so you can make small changes and see their effects while developing.

All the docker containers for the database setup are tagged with a docker-compose project name, so we could use a second project name for each use case. Then we can always reset / clear the "testing" project after each run, but leave the "debug" project alone and let the developer manually clear it when they need to.

@yusefnapora yusefnapora added kind/enhancement A net-new feature or improvement to an existing feature kind/maintenance Work required to avoid breaking changes or harm to project's status quo effort/hours Estimated to take one or several hours status/ready Ready to be worked topic/devexp Developer Experience pi/support-0 labels Mar 22, 2022
@yusefnapora yusefnapora self-assigned this Mar 22, 2022
@yusefnapora
Copy link
Contributor Author

Note that we should bind to non-default ports where possible to avoid conflicts with everything that wants to run on port 3000, etc.

If it's easy to bind to ephemeral ports and automatically set the correct env variables, let's do that :)

@redaphid
Copy link
Contributor

We could look into docker compose overrides for this.

@redaphid
Copy link
Contributor

Also:

  • Remove container_name from docker-compose keys, so there aren't collisions and we keep the env self-contained
  • Minimize when we need to expose ports in general - and maybe don't expose them by default
  • Maybe there's some simple dns solution?

@yusefnapora
Copy link
Contributor Author

If we're willing to run everything inside containers (including miniflare and the frontend dev server), we could probably get away with just exposing the port for the frontend. Everything else could use the internal docker network by default, although you should be able to flip a switch to expose what you need for debugging.

That means we'd need to bind-mount the source tree into the container, so changes are picked up as you edit. Adding a devcontainers.json for VS Code integration could help, but not everyone uses VS Code, so it's not a perfect solution.

I'm not saying we definitely should do this, btw... just tossing it out there as something to consider.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/hours Estimated to take one or several hours kind/enhancement A net-new feature or improvement to an existing feature kind/maintenance Work required to avoid breaking changes or harm to project's status quo pi/support-0 status/ready Ready to be worked topic/devexp Developer Experience
Projects
None yet
Development

No branches or pull requests

3 participants