Lucas Orth
f5bdb9a988
Statt eines zweiten Repos wird deploy-kit selbst die Vorlage. Ein Template
kopiert das gesamte Repo, die Projektdateien muessen also im Wurzel-
verzeichnis liegen - template/ ist entsprechend aufgeloest.
- bootstrap.sh entfaellt: das Template uebernimmt seine Aufgabe, und
Gitea kopiert serverseitig, funktioniert also auch bei privatem Repo.
- .gitea/template laesst Gitea ${REPO_NAME} in README.md und
docker-compose.yml ersetzen. Projektname, Image und container_name
stimmen damit ohne Handarbeit, offen bleibt nur der Port.
- CLAUDE.md zeigt auf DEPLOY.md, damit die Konventionen beim Arbeiten am
erzeugten Projekt gelesen werden.
- DEPLOY.md liegt jetzt nur noch einmal - die Kopie im geplanten zweiten
Repo waere unweigerlich auseinandergelaufen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1005 B
1005 B
Projekthinweise
Deployment
Diese App wird per Tag-Push deployt, nicht manuell hochgeladen.
Die verbindlichen Konventionen stehen in DEPLOY.md. Vor Aenderungen an
Dockerfile, docker-compose.yml oder .gitea/workflows/ dort nachsehen.
Kurzfassung der Regeln, die man leicht bricht:
- Kein
ports:im Compose. Der Proxy erreicht den Container ueber das Netznginx-proxy-manager_defaultunter seinemcontainer_name. name:im Compose ist Pflicht (fester Projektname), sonst legt der CI-Job einen zweiten Stack an.- Keine relativen Bind-Mounts. Compose laeuft im Job-Container, der Pfad
zeigt auf dem Host ins Leere. Persistente Daten in named volumes mit
festem
name:. - Healthcheck ist Pflicht, der Deploy nutzt ihn als Gate.
- Secrets kommen aus dem Repo-Secret
DOTENV, nie in die Compose-Datei.
Noch offen in diesem Repo
Nach dem Anlegen aus der Vorlage sind __APP__ und __PORT__ zu ersetzen
und das Dockerfile an den Stack anzupassen. Details in README.md.