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>
${REPO_NAME}
Aus der Vorlage deploy-kit erzeugt.
Einrichten
1. Port setzen. Den App-Namen hat Gitea beim Anlegen aus dem Repo-Namen eingesetzt. Offen ist nur noch der Port:
sed -i "s/__PORT__/3000/g" docker-compose.yml Dockerfile
Auf den Port anpassen, auf dem die App tatsaechlich lauscht.
2. Dockerfile anpassen. Die Vorlage ist fuer Node mit TypeScript-Build.
3. Build- und Test-Schritte in .gitea/workflows/deploy.yml
einkommentieren.
4. Healthcheck in docker-compose.yml auf einen echten Endpoint zeigen
lassen. Er ist das Gate des Deploy-Schritts - zeigt er ins Leere, schlaegt
jeder Deploy fehl.
5. Secret DOTENV anlegen: Einstellungen -> Actions -> Secrets, mit dem
kompletten .env-Inhalt, mehrzeilig.
6. Proxy Host im Nginx Proxy Manager:
${REPO_NAME}.lucas-orth.de -> ${REPO_NAME} : Port aus Schritt 1.
7. Deployen:
git tag v1.0.0 && git push origin v1.0.0
Pruefen, bevor der erste Tag faellt
grep -n '__APP__\|__PORT__\|\${REPO_NAME}' docker-compose.yml Dockerfile
Kein Treffer heisst: alles ersetzt.
Falls in docker-compose.yml ${IMAGE_TAG:-latest} verstuemmelt ist, hat
die Template-Ersetzung zu viel angefasst - dann docker-compose.yml aus
.gitea/template streichen und die Platzhalter von Hand setzen.
Konventionen
DEPLOY.md - verbindlich, liegt im Projekt.
MIGRATION.md gilt nur, wenn diese App vorher schon manuell auf dem Server lief. Bei einem neuen Projekt kann die Datei geloescht werden.