Stefan Mogeritsch f470e88e9f docs: add roadmap for Zora infrastructure deployment and "Hello-World" test guide

Added two new documents, `Zora_Infrastructure&Deployment_02-2026.md` and `Temp.md`, detailing the strategic roadmap for Zora's infrastructure setup and deployment phases, alongside a "Hello-World" test project guide to validate CI/CD pipelines and ARM64 compatibility.

2026-02-12 20:35:25 +01:00

3.0 KiB

Raw Blame History

„Hello-World“-Testprojekt

Bevor das "Meldestelle"-Projekt auf Zora losgelassen wird, erstellen wir ein "Hallo Welt"-Projekt. Das spart Zeit beim Debugging, wenn der Test-Build fehlschlägt, wissen wir sofort, es liegt an der Infrastruktur (Runner/Registry) und nicht an komplexen Gradle-Abhängigkeiten.

Plan für "Sandbox-Projekt“, um die CI/CD-Leitung auf Zora zu testen.

1. Runner-Stabilisierung: Der „Herz-Check“

Bevor das Testprojekt gepusht wird, müssen wir sicherstellen, dass der Runner nicht nur „jetzt“ online war, sondern als stabiler Dienst im Hintergrund läuft.

Checke das im Container infra-runner:

incus exec infra-runner -- systemctl status act_runner

Wenn „active (running)“: Alles bestens.
Falls nicht: Starte ihn mit systemctl enable --now act_runner.
Gitea-Check: Im Browser sollte der Status jetzt von Inaktiv (Grau/Gelb) auf Aktiv (Grün) springen, sobald der Dienst läuft.

2. Das Test-Projekt: „Zora-Proof-of-Concept“

Erstelle in deiner IDEA (oder direkt in Gitea) ein neues, leeres Repository namens zora-test.

A. Die minimale Dockerfile

Wir nehmen ein extrem kleines Image, um die ARM64-Fähigkeit zu testen:

FROM alpine:latest
RUN echo "Zora hat dieses Image gebaut!" > /hello.txt
CMD ["cat", "/hello.txt"]

B. Der Workflow (`.gitea/workflows/test.yaml`)

Hier nutzen wir deine neuen Secrets REGISTRY_TOKEN und REGISTRY_USER.

name: Zora Test Build
on: [push]
jobs:
  build-and-push:
    runs-on: ubuntu-latest # Dein Runner erkennt das Label
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      
      - name: Login to Registry
        uses: docker/login-action@v3
        with:
          registry: git.mo-code.at
          username: ${{ secrets.REGISTRY_USER }}
          password: ${{ secrets.REGISTRY_TOKEN }}

      - name: Build and Push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: git.mo-code.at/${{ secrets.REGISTRY_USER }}/zora-test:latest

3. Warum dieser Test so wertvoll ist

Registry-Rechte: Wir prüfen, ob dein neuer Token wirklich Pakete schreiben darf.
LXC-Docker-Check: Wir sehen, ob Docker im Container infra-runner mit dem fuse-overlayfs Treiber wirklich Images bauen kann.
ARM64-Verifizierung: Wir bestätigen, dass der Runner das Image nativ für dein Biest baut.

Was wir kontrollieren müssen (Erfolgskriterien):

Erscheint in Gitea unter dem Reiter „Actions“ ein neuer Eintrag nach dem Push?
Läuft der Build ohne Fehler durch?
Taucht unter deinem Profil in Gitea ein neues „Paket“ namens zora-test auf?

Soll ich dir, sobald du das Testprojekt in Gitea angelegt hast, helfen das Log-Streaming des Runners zu analysieren, falls er beim docker login hängen bleibt? (Das ist oft die Stelle, an der falsche Secret-Namen auffallen).

3.0 KiB Raw Blame History