# **„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`:**

```bash
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:

```dockerfile
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`.

```yaml
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

1. **Registry-Rechte:** Wir prüfen, ob dein neuer Token wirklich Pakete schreiben darf.
2. **LXC-Docker-Check:** Wir sehen, ob Docker im Container `infra-runner` mit dem `fuse-overlayfs` Treiber wirklich Images bauen kann.
3. **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).