Der Minimal-Workflow diente dem Nachweis, dass es nicht an der YAML
liegt: auch acht Zeilen erzeugen keinen Lauf. Auf der gesamten Instanz
existiert in keinem Repo je ein Actions-Lauf, obwohl docker-runner-01
online ist und das Label ubuntu-latest fuehrt.
build.yml bleibt liegen, falls die Runner-Anbindung spaeter repariert
wird. Deployt wird bis dahin ueber den Portainer-Git-Stack.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
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>
