From 28e0f5d1a0b860bad88a7d111f9aace00da2476c Mon Sep 17 00:00:00 2001
From: Geoffrey Gilmore <tkdmaster123@gmail.com>
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