Docker-Image bauen / build (push) Successful in 1m31s
Der bisherige Schritt hängte das Arbeitsverzeichnis mit -v "$PWD":/app in einen Container. Läuft der Gitea-Runner selbst in einem Container, zeigt $PWD auf einen Pfad, den der Docker-Daemon des Hosts nicht kennt: der Mount wäre leer, pytest fände keine Tests und meldete Erfolg. Wieder ein Test, der nicht hätte fehlschlagen können. Jetzt über Dockerfile.test - der Code kommt über den Build-Kontext hinein, unabhängig davon, wie der Runner aufgebaut ist. tests/ bleibt dafür im Kontext; das Anwendungs-Image kopiert sie weiterhin nicht mit. Lokal genauso ausgeführt wie die CI es tun wird: 81 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GR4bNaj9GtRu57J4Niii8o
33 lines
631 B
Plaintext
33 lines
631 B
Plaintext
# Was nicht in den Build-Kontext gehört.
|
|
#
|
|
# Das Dockerfile kopiert ohnehin nur gezielt einzelne Verzeichnisse, es
|
|
# landet also nichts davon im Image. Aber der gesamte Kontext wird an den
|
|
# Docker-Daemon übertragen - und .env enthält das Admin-Passwort.
|
|
|
|
.env
|
|
.git
|
|
.gitea
|
|
.github
|
|
.claude
|
|
|
|
# Laufzeitdaten (im Betrieb Volumes)
|
|
data/
|
|
uploads/
|
|
*.sqlite
|
|
*.sqlite3
|
|
|
|
# Entwicklung
|
|
# tests/ bleibt bewusst im Kontext: Dockerfile.test braucht sie.
|
|
# Das Anwendungs-Image kopiert sie nicht mit.
|
|
.pytest_cache/
|
|
.venv/
|
|
venv/
|
|
__pycache__/
|
|
*.py[cod]
|
|
|
|
# Wird im Build erzeugt bzw. nur dort gebraucht
|
|
tailwindcss
|
|
Plan.md
|
|
projekt.md
|
|
README.md
|