You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Somewhere along my build process, I collect static to copy them to a nginx static file server.
# In a dockerfile
RUN python manage.py collectstatic --settings=core.settings.production --noinput
core/settings/production.py does not have a fixed SECRET_KEY defined, it refers to env var thus it crashes.
$ poetry run python manage.py collect-static --settings=core.settings.production
[...]
from django_q.conf import Conf
File "/.../python3.12/site-packages/django_q/conf.py", line 42, in <module>
class Conf:
File "/.../python3.12/site-packages/django_q/conf.py", line 209, in Conf
SECRET_KEY = settings.SECRET_KEY
^^^^^^^^^^^^^^^^^^^
File "/.../python3.12/site-packages/django/conf/__init__.py", line 111, in __getattr__
raise ImproperlyConfigured("The SECRET_KEY setting must not be empty.")
django.core.exceptions.ImproperlyConfigured: The SECRET_KEY setting must not be empty.
Having to define the SECRET_KEY in the build process feels very wrong. As such I cannot have a single image to be deployed multiple times if this SECRET_KEY is truly used.
Our simple solution is to set this var:
RUN SECRET_KEY=notimportant python manage.py collectstatic --settings=core.settings.production --noinput
however I am afraid that this SECRET_KEY might be used somewhere around there.
Could we envision a django_q that would not requires this SECRET_KEY in such step, i.e only when needed at runtime?
The text was updated successfully, but these errors were encountered:
Somewhere along my build process, I collect static to copy them to a nginx static file server.
core/settings/production.py does not have a fixed SECRET_KEY defined, it refers to env var thus it crashes.
Having to define the SECRET_KEY in the build process feels very wrong. As such I cannot have a single image to be deployed multiple times if this SECRET_KEY is truly used.
Our simple solution is to set this var:
however I am afraid that this SECRET_KEY might be used somewhere around there.
Could we envision a django_q that would not requires this SECRET_KEY in such step, i.e only when needed at runtime?
The text was updated successfully, but these errors were encountered: