docker-compose: explicitly define COMPOSE_PROJECT_NAME

[ggilmore]

COMPOSE_PROJECT_NAME defines a namespace that docker-compose prefixes all networks, containers, and volumes with. This environment variable wasn't previously set, in which case docker-compose defaults COMPOSE_PROJECT_NAME to the basename of the folder that contains the docker-compose.yaml file (literally docker-compose in our case).

Not defining this variable has worked up until now, but docker-compose will treat all resources defined in docker-compose.yaml as brand new if the folder contains docker-compose.yaml was ever renamed. All the data from the old volumes will have to be manually moved over. Defining this environment variable (and making sure all docker-compose commands are run relative to this file) will prevent this from happening.

I debated between two values for COMPOSE_PROJECT_NAME:

• docker-compose
• sourcegraph-docker-compose.

docker-compose should allow our existing users to upgrade without any manual migrations, but it's more ambiguous than sourcegraph-docker-compose. We could choose to set COMPOSE_PROJECT_NAME=sourcegraph-docker-compose, but we'll need to figure out a migration path for our existing users (dump the PostgreSQL database?) .

[ggilmore]

cc @slimsag PTAL and weigh in

[emidoots]

docker-compose should allow our existing users to upgrade without any manual migrations, but it's more ambiguous than sourcegraph-docker-compose

I think that docker-compose is fine for almost all deployments because in most cases Soucegraph is being deployed on a VM without any other Docker resources, i.e. "we own the machine" If it's not OK on someone's machine, they could also change it.

If we start trying to suggest the docker-compose method over the server method for dev laptop deployments, we would want to do something else.