5 Commits

Include renames

Author	SHA1	Message	Date
rorappandClaude Opus 5	4290fa78d3	Actions-Workflow testweise wieder aufnehmen ... Rein additiv: docker-compose.yml und der laufende Portainer-Stack bleiben unberuehrt. Faellt der Lauf durch, aendert sich am Deployment nichts. Zweck ist herauszufinden, ob der Runner ueberhaupt anspringt und ob er den Docker-Socket in den Job-Container reicht. Der Schritt "Umgebung protokollieren" gibt genau das aus, ohne selbst fehlzuschlagen. Die Secrets REGISTRY_USER und REGISTRY_TOKEN sind gesetzt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 01:30:58 +02:00
rorappandClaude Opus 5	1dd92d97cb	Deployment auf Portainer-Git-Stack umstellen ... 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>	2026-08-31 00:22:07 +02:00
rorappandClaude Opus 5	2bdf0b2e11	Workflow an den Runner anpassen: Docker-CLI nachruesten, kein buildx ... 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>	2026-08-31 00:13:07 +02:00
rorappandClaude Opus 5	d20d25ff32	Workflow ohne docker/*-Actions, nur mit Shell-Schritten ... 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>	2026-08-31 00:07:02 +02:00
rorappandClaude Opus 5	30d15cd680	Image in der CI bauen statt zur Laufzeit, Site ins Image backen ... 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>	2026-08-31 00:01:17 +02:00