docker/setup-buildx-action und docker/build-push-action muessen vom
Runner erst von github.com nachgeladen werden. Auf selbst gehosteten
Gitea-Instanzen scheitert das haeufig, und der Job bricht ab, bevor
ueberhaupt gebaut wird.
Die Schritte machen jetzt dasselbe mit direkten docker-buildx-Befehlen -
identisch zu dem, was im Jenkinsfile von lichterei-web nachweislich
funktioniert. Damit bleibt actions/checkout die einzige externe
Abhaengigkeit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bisher baute der Server das Image selbst und der Container holte sich
Inhalte per git pull ueber deploy.php. Das war seit jeher kaputt: git
verweigerte wegen "dubious ownership" die Arbeit, die &&-Kette brach ab,
hugo lief nie. Live war stets der Stand des letzten Containerstarts.
Statt das zu flicken faellt der Mechanismus jetzt weg. Das Dockerfile
ist zweistufig: Hugo baut die Seite im Builder, das Laufzeit-Image
enthaelt nur nginx und fertiges HTML. Kein PHP, kein git, kein Hugo mehr
zur Laufzeit - 49 MB statt eines Debian-Images mit vier Werkzeugketten.
Deployen heisst damit: neues Image ziehen, Container neu starten.
Entfernt: deploy.php, entrypoint.sh und .htaccess (Apache-Rest aus der
Kirby-Zeit, unter nginx wirkungslos). Der Ordner kirby/ heisst jetzt
docker/, weil dort nie Kirby lag.
docker-compose.yml zieht das Image aus der Registry. Das Volume-Mount
auf /var/www/html ist weg - es haette die ins Image gebackene Seite
verdeckt.
Lokal geprueft: Build laeuft durch, Container liefert alle Seiten und
Assets mit HTTP 200 aus, Intro-Text kommt aus der Markdown-Datei, alle
sieben Lampenbilder sind enthalten.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
