ci: migrate workflows to Gitea Actions

README.md

@@ -55,7 +55,7 @@ und TLS-Konfiguration stehen in der [Betriebsanleitung](docs/operations.md).
 
 Auf dem Zielserver werden Docker Engine, das Compose-Plugin und ein
 HTTPS-Reverse-Proxy benötigt. Die Anwendung wird als fertiges Image aus der
-GitHub Container Registry (GHCR) heruntergeladen. Quellcode und Build-Werkzeuge werden
+Container Registry der Gitea-Instanz heruntergeladen. Quellcode und Build-Werkzeuge werden
 für das Deployment nicht benötigt.
 
 [compose.yaml](compose.yaml) und die [Umgebungsvorlage](config/deployment.env.example)
@@ -67,14 +67,14 @@ einen bereits veröffentlichten Versionstag aus der Projektregistry verwenden.
 Compose benötigt ausdrücklich `PROVISIONER_IMAGE`; ein lokaler Build ist nicht
 Teil dieser Deployment-Konfiguration.
 
-Im Deployment-Verzeichnis ausführen. Für ein privates GHCR-Paket beim Login den
-eigenen GitHub-Benutzernamen und einen Personal Access Token (classic) mit
-`read:packages` als Passwort verwenden. Bei einem öffentlichen Paket entfällt
+Im Deployment-Verzeichnis ausführen. Für ein privates Gitea-Paket beim Login den
+eigenen Gitea-Benutzernamen und einen Personal Access Token mit
+`read:package` als Passwort verwenden. Bei einem öffentlichen Paket entfällt
 der Login. Details stehen unter [Registry-Anmeldung](docs/deployment.md#an-der-registry-anmelden-und-image-laden).
 
 ```bash
-# Nur für ein privates Paket; GITHUB_USERNAME ersetzen:
-docker login ghcr.io --username GITHUB_USERNAME
+# Nur für ein privates Paket; GITEA_USERNAME ersetzen:
+docker login gitlab.bartelluis.de --username GITEA_USERNAME
 docker compose config --quiet
 docker compose pull provisioner
 # Nur bei der ersten Inbetriebnahme:
@@ -91,20 +91,25 @@ Master-Key getrennt in `proxmox-ais-keys`.
 Die [Deployment-Anleitung](docs/deployment.md) beschreibt Image-Auswahl,
 Erstinitialisierung, Updates, Rollback und die Prüfung des laufenden Containers.
 
-## GitHub Actions CI/CD
+## Gitea Actions CI/CD
 
-Der [GitHub-Actions-Workflow](.github/workflows/ci.yml) prüft Python und JavaScript, baut das Image
+Das Projekt liegt auf [Gitea](https://gitlab.bartelluis.de/BartelLuis/Proxmox-AIS-Server).
+Der [Gitea-Actions-Workflow](.gitea/workflows/ci.yml) prüft Python und JavaScript, baut das Image
 und testet HTTPS, Anmeldung und Datenerhalt beim Neustart im gehärteten Container.
-Geschützte Standardbranch-Pushes veröffentlichen `sha-<Commit>` und `edge` in
-`ghcr.io/netivra/proxmox-ais`; geschützte Release-Tags wie `v0.1.0` zusätzlich
-die passende Versionsnummer. Feature-Branches und Pull Requests werden ohne Push geprüft.
+Bei aktivierter Veröffentlichung (`PUBLISH_IMAGES=true`) veröffentlichen
+Standardbranch-Pushes `sha-<Commit>` und `edge` in
+`gitlab.bartelluis.de/bartelluis/proxmox-ais-server`; Release-Tags wie `v0.1.0`
+zusätzlich die passende Versionsnummer. Feature-Branches und Pull Requests
+werden ohne Registry-Push geprüft.
 
-Die Jobs verwenden GitHub-gehostete Runner mit `ubuntu-24.04`, Python 3.13,
-Node.js 24 und Docker/Buildx. Ein eigener CI-Runner ist nicht erforderlich.
-Für die Veröffentlichung müssen der Standardbranch und die Release-Tags durch
-aktive GitHub-Regeln geschützt sein. GHCR erhält das automatisch bereitgestellte
-`GITHUB_TOKEN`; ein eigenes CI-Secret wird nicht benötigt. Einrichtung,
-Schutzregeln und Artefakte stehen in der [GitHub-Anleitung](docs/github-actions.md).
+Gitea benötigt einen registrierten, erreichbaren Linux-amd64-Runner. Das
+Runner-Label ist über `AIS_RUNNER_LABEL` wählbar und lautet standardmäßig
+`ubuntu-latest`. Die Build-Umgebung benötigt Python 3.13, Node.js 24 und
+Docker/Buildx. Für die Veröffentlichung werden die Variable `REGISTRY_USERNAME`
+und das Secret `REGISTRY_TOKEN` mit `write:package` eingerichtet. Standardbranch
+und Release-Tags in Gitea schützen, bevor `PUBLISH_IMAGES` aktiviert wird.
+Runner-Einrichtung, Schutzregeln und Artefakte stehen in der
+[Gitea-Anleitung](docs/gitea-actions.md).
 
 Die Pipeline liefert das getestete Image und dessen Digest in `deploy.env`.
 Die Installation auf dem Zielserver folgt der [Deployment-Anleitung](docs/deployment.md).