CI / test (push) Has been cancelled
- bin/build-and-push.sh: baut + pusht Image in die Gitea-Registry unter git.pkop.de/vibecode/watchlist:<version> - bin/get-version.py: liest __version__ aus app/__init__.py (single source of truth, kein Quoting-Wahnsinn in Bash) - bin/build-image.sh + write-manifest.sh nutzen den neuen Helper - dist/README.md: erklärt die Registry-Policy (kein Tar im Repo) - load-image.sh entfernt — Tars gibt's nicht mehr - .gitignore: dist/*.tar + manifest.json ausschließen, dist/README.md bleibt dokumentiert - docker-compose.yml: Hinweis auf Registry-Image - CI-Workflow: vereinfacht, Push läuft lokal (idempotent) - Version auf 0.5.1-beta gebumpt Verifiziert end-to-end: bin/build-and-push.sh -> Image in Gitea-Registry docker rmi ... -> lokal weg docker pull ... -> aus Registry gezogen docker run ... -> startet, version 0.5.1-beta, 8 unique Items
dist/ — leeres Build-Ausgabeverzeichnis
Docker-Images werden nicht als Tar im Repo committed, sondern in die Gitea Container Registry gepusht (siehe Packages-Tab im Repo-UI).
Verwendung der Registry-Images
docker pull git.pkop.de/vibecode/watchlist:0.5.1-beta
docker run -d --name watchstack -p 8000:8000 -v watchstack-data:/data \
git.pkop.de/vibecode/watchlist:0.5.1-beta
Build + Push lokal
bin/build-and-push.sh # baut + pusht mit Version aus app/__init__.py
VERSION=0.6.0 bin/build-and-push.sh # baut + pusht mit expliziter Version
Warum kein Tar im Repo?
- Gitea hat eine eingebaute OCI-Registry, perfekt für Docker-Images
- Tars diffen/duplizieren schlecht
- "Packages"-Tab im Gitea-Web-UI ist übersichtlicher als eine Tar-Datei
- Online und offline nutzbar via
docker pull(vs. nurdocker load)
Wenn du das Image ohne Netzwerk brauchst, kannst du es auf einer Online-Maschine
pullen und per docker save weitergeben — aber das ist eine andere Deployment-Form.