mrwnslz/diora-web
1
0
Fork 0
Code Issues 4 Pull requests Projects Releases Packages Wiki Activity Actions

Alle Abhängigkeiten pinnen; STATICFILES_STORAGE auf STORAGES umstellen
Some checks failed
Build and push Docker image / build (push) Successful in 12s
Details
Test / test (push) Failing after 6s
Details

Browse source 
requirements.txt stand durchgehend auf ">=", die gebaute Version hing also am
Kalendertag statt am Repo. Genau daran ist der letzte Deploy gescheitert.
Jetzt exakt die Versionen, gegen die die Suite grün ist und die produktiv
laufen — Updates werden damit zu einer bewussten Änderung mit CI-Lauf.

Django bleibt auf 6.1: dorthin ist die Instanz ohnehin schon gedriftet, es
läuft, und 4.2 LTS ist seit April 2026 aus dem Support.

Dabei ist aufgefallen, dass Django 5.1 STATICFILES_STORAGE entfernt hat. Die
Einstellung stand noch da und wurde stillschweigend ignoriert, womit
whitenoise auf StaticFilesStorage zurückfiel und Assets unkomprimiert
auslieferte — app.js mit 251 KB statt 62 KB bei jedem kalten Laden.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
marwin 2026-08-28 08:50:47 +00:00
parent 0b62fbc0de
commit 23798cda01
2 changed files with 34 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
diora/settings.py
View file

@ -97,7 +97,23 @@ STATIC_URL = '/static/'
STATICFILES_DIRS = [BASE_DIR / 'static'] STATICFILES_DIRS = [BASE_DIR / 'static']
STATIC_ROOT = BASE_DIR / 'staticfiles' STATIC_ROOT = BASE_DIR / 'staticfiles'
STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage' # Django 5.1 removed STATICFILES_STORAGE in favour of STORAGES. The old setting
# sat here being silently ignored, so whitenoise fell back to plain
# StaticFilesStorage and served everything uncompressed — app.js went out at
# 251 KB instead of 62 KB on every cold load.
#
# The hashed filenames this also generates are inert: no template uses
# {% static %}, they all hardcode /static/… paths. Cache busting comes from the
# service worker's CACHE version instead (static/js/sw.js), which is why it is
# bumped on each release.
STORAGES = {
'default': {
'BACKEND': 'django.core.files.storage.FileSystemStorage',
},
'staticfiles': {
'BACKEND': 'whitenoise.storage.CompressedManifestStaticFilesStorage',
},
}
MEDIA_URL = '/media/' MEDIA_URL = '/media/'
MEDIA_ROOT = BASE_DIR / 'media' MEDIA_ROOT = BASE_DIR / 'media'

29
requirements.txt
View file

@ -1,13 +1,18 @@
django>=4.2 # Pinned to exact versions. These are what production runs and what the test
pylast>=5.2 # suite is green against — with `>=` the image you get depends on the day you
requests>=2.31 # build it, which is how a rebuild once swapped in a gunicorn that could not
python-dotenv>=1.0 # boot the gevent worker at all.
whitenoise>=6.6 #
feedparser>=6.0 # Nothing here updates on its own any more, so bump deliberately: change a
gevent>=24.0 # version, let CI run, then deploy.
# Pinned: 26.2.0 ships ggevent.py importing packaging.version while declaring Django==6.1
# no dependencies at all, so the gevent worker dies at boot unless packaging is pylast==7.1.0
# installed explicitly. Both stay pinned here rather than being pulled in bare requests==2.34.2
# by the Dockerfile, so a rebuild cannot silently change the worker again. python-dotenv==1.2.3
whitenoise==6.12.0
feedparser==6.0.14
gevent==26.8.0
# gunicorn 26.2.0 imports packaging.version in ggevent.py while declaring no
# dependencies of its own, so packaging has to be requested explicitly.
gunicorn==26.2.0 gunicorn==26.2.0
packaging>=24.0 packaging==26.3