-
Notifications
You must be signed in to change notification settings - Fork 4
/
docker-project-command.sh
executable file
·53 lines (45 loc) · 2.09 KB
/
docker-project-command.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
#!/bin/sh
set -eu
# These are build dependencies for some of the Python packages in
# requirements.txt.
apk add gcc g++ libstdc++ libffi-dev musl-dev openssl-dev postgresql-dev
pip install -r requirements.txt
# Honcho runs the Procfile in the dev environment, and watchdog (watchmedo)
# handles restarting on file changes; they aren't needed in Heroku.
pip install honcho watchdog
# If the database doesn't already exist, this initializes it.
herring/manage.py makemigrations
herring/manage.py migrate
# This assembles the staticfiles directory; Heroku performs this step
# automatically when it detects an appropriate Django app, so there is no need
# to commit the directory to Git.
herring/manage.py collectstatic --noinput --clear --link
# An easier way to create an admin user interactively is to call
# `herring/manage.py createsuperuser`, but it throws an error if the user
# already exists.
herring/manage.py shell <<EOF
from django.contrib.auth import get_user_model
users = get_user_model().objects
if not users.filter(username='admin').exists():
users.create_superuser('admin', password='admin')
EOF
# gunicorn-dev.py configures Gunicorn to watch for file changes and reload
# automatically. It may eventually contain other settings exclusive to the dev
# environment.
#
# PYTHONUNBUFFERED=true keeps the output of the Procfile commands flowing;
# without that, Python buffers stdout when it is connected to a process like
# Honcho.
#
# We don't want Honcho to pull from the .env file, because docker-compose.yml
# already imports it, and Honcho and Compose disagree on how to interpret
# quotation marks and escape sequences. Instead, we point it at /dev/null.
#
# Finally, we run two copies of the worker process, both to ensure that there's
# enough concurrency despite the long-running Discord task that will occupy one
# of the worker subprocesses indefinitely, and to test that Celery Beat is
# configured such that scaling up workers doesn't cause tasks to be
# double-scheduled.
GUNICORN_CMD_ARGS="-c python:gunicorn-dev" \
PYTHONUNBUFFERED=true \
exec honcho -e /dev/null -f Procfile.dev start -c worker=2