From 28e0f5d1a0b860bad88a7d111f9aace00da2476c Mon Sep 17 00:00:00 2001 From: Geoffrey Gilmore Date: Thu, 13 Feb 2020 17:09:15 -0800 Subject: [PATCH] docker-compose: explicitly define COMPOSE_PROJECT_NAME [COMPOSE_PROJECT_NAME](https://docs.docker.com/compose/reference/envvars/#compose_project_name) defines a namespace that docker-compose prefixes all networks, containers, and volumes with. This previously wasn't 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.yam` 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` and `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 postgres database?) . --- docker-compose/.env | 1 + 1 file changed, 1 insertion(+) create mode 100644 docker-compose/.env diff --git a/docker-compose/.env b/docker-compose/.env new file mode 100644 index 000000000..0afc2193c --- /dev/null +++ b/docker-compose/.env @@ -0,0 +1 @@ +COMPOSE_PROJECT_NAME=docker-compose