Ein normaler git clone holt Submodules nicht mit - geprueft: nach dem
Klonen des Repos war themes/gokarna leer. Portainer klont ebenso, der
Build im Container waere also an dem fehlenden Theme gescheitert.
Gokarna liegt jetzt direkt im Repo, festgeschrieben auf Commit 8306042,
den Stand, mit dem die Seite bisher gebaut wurde. .gitmodules entfaellt.
Nachteil: Theme-Updates muessen kuenftig von Hand eingespielt werden.
Dafuer baut das Repo aus jedem beliebigen Klon heraus, ohne
Sonderbehandlung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Neue Lampe lampe0.jpg samt Eintrag in der lampen-Liste - erste
Inhaltsaenderung ueber die neue Frontmatter-Struktur, ohne Eingriff ins
Template.
Nav-Links auf der Lichterei-Seite gestylt (uebernommen aus der lokalen
Aenderung an lichterei.css).
Festivals-Seite: Festival am Waldrand und die dort dokumentierte Rolle
des Art:Al-Kollektivs, belegt aus der Informationen-Seite des
Veranstalters. Die Abschnitte zu Art:Al selbst und zu weiteren
Beteiligungen stehen als Kommentar im Quelltext, bis die Angaben dazu
vorliegen - so rendert die Seite keine leeren Ueberschriften.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gitea Actions entfaellt. Der Runner laeuft in node:20-bookworm ohne
Docker-CLI und ohne Daemon; jeder Bauversuch scheiterte dort, und die
Nachruest-Loesung haette am durchgereichten Socket gehangen, der
moeglicherweise gar nicht existiert.
Stattdessen baut Portainer selbst aus diesem Repo. docker-compose.yml
steht dafuer wieder auf build: mit dem mehrstufigen docker/Dockerfile.
Damit entfaellt die Registry komplett - kein Image-Push, keine
Zugangsdaten, weder fuer die CI noch fuer Portainer, weil das Repo
oeffentlich lesbar ist.
Der Aufbau des Images bleibt unveraendert: Hugo baut die Seite im
Builder, das Laufzeit-Image ist reines nginx mit fertigem HTML.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Runner ist mit ubuntu-latest:docker://node:20-bookworm registriert,
Jobs laufen also in einem node-Image. Darin gibt es weder docker-CLI
noch Daemon - jeder docker-Aufruf scheiterte an "command not found",
unabhaengig davon ob als Action oder als Shell-Schritt.
Der Job laedt jetzt die statische docker-CLI (ohne Daemon) nach und
baut ueber den vom Runner durchgereichten Socket. buildx entfaellt: der
Runner ist amd64, ein einfacher docker build genuegt und spart die
Plugin-Installation.
Ein vorgeschalteter Schritt protokolliert CLI, Socket und DOCKER_HOST,
ohne selbst fehlzuschlagen - damit im Log steht, woran es liegt, falls
der Socket nicht durchgereicht wird.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Der Webhook lief, brach aber sofort ab:
fatal: detected dubious ownership in repository at '/var/www/html'
Das Repo gehoert einem anderen Benutzer als dem, unter dem PHP-FPM
laeuft. Git verweigert daraufhin jede Operation, und weil deploy.php
die Schritte mit && verkettet, wurde hugo nie erreicht. Auf main
gepushte Aenderungen gingen deshalb nie live - die Seite zeigte immer
den Stand des letzten Containerstarts, weil nur der Entrypoint als
root gebaut hat.
Der Entrypoint traegt jetzt systemweit safe.directory fuer das Repo
und das Theme-Submodule ein und uebergibt das Verzeichnis an www-data,
damit git pull und der hugo-Build tatsaechlich schreiben koennen.
Greift erst nach einem Neubau des Containers - der laufende Container
kann sich nicht selbst reparieren.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Einleitungstext und Bildliste standen fest verdrahtet in
layouts/lampe/single.html, die Galerie lief ueber ein hartes
"range seq 1 7". Inhaltliche Aenderungen erforderten damit
Eingriffe ins Template.
Der Text steht jetzt als Fliesstext in lichterei.md und wird ueber
.Content gerendert, die Bilder als Liste "lampen" im Frontmatter mit
optionaler Bildunterschrift. Das Template iteriert ueber die Liste,
statt auf sieben Eintraege festgelegt zu sein.
Leerer text-Wert unterdrueckt die figcaption und laesst den alt-Text
auf "Lampe N" zurueckfallen - die Seite rendert damit unveraendert.
Ausserdem: AGENTS.md als Arbeitsanweisung fuer die lokale
LLM-gestuetzte Bearbeitung, CSS-Regel fuer figcaption ergaenzt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Remove all Kirby/PHP files
- Add Hugo config with Gokarna theme as git submodule
- Add nginx + Hugo Dockerfile replacing PHP/Apache
- Update deploy.php to run hugo after git pull
- Update .gitignore for Hugo output
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>