stefan
f470e88e9f
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.
88 lines
3.0 KiB
Markdown
88 lines
3.0 KiB
Markdown
# **„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).
|