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>
25 lines
1005 B
Markdown
25 lines
1005 B
Markdown
# 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 Netz
|
|
`nginx-proxy-manager_default` unter seinem `container_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.
|