Orchestrator/bahn/O2C-Harness/workflow.md

# Workflow

## Ablauf bei bestehendem Repo

1. Repo klonen (`git clone $REPO_URL`)
2. Feature-Branch erstellen (`git checkout -b $BRANCH`)
3. Implementieren
4. Tests schreiben und ausführen (80% Coverage)
5. gitleaks ausführen
6. Linting/Formatting anwenden
7. Commit mit Conventional Commits Message
8. Push auf Feature-Branch
9. Merge Request erstellen mit `glab mr create`

## Ablauf wenn Repo nicht existiert (neues Projekt)

1. Repo in GitLab anlegen mit `glab`:
   ```bash
   glab repo create {repo-name} --group {group} --internal --description "{beschreibung}"
   ```
   - GitLab Host: https://git.tech.rz.db.de
   - Gruppe kommt aus REPO_URL oder aus der Aufgabe (z.B. "GitLab Group: ${ART_NAME}/playground")

2. Lokal initialisieren auf **main** Branch:
   ```bash
   mkdir project && cd project
   git init
   git remote add origin https://git.tech.rz.db.de/{group}/{project}.git
   git checkout -b main
   ```

3. **Pflichtdateien zuerst** (siehe project-setup.md):
   - README.md (mit Projektbeschreibung, Quickstart, Build/Test Anleitung)
   - LICENSE.adoc
   - scm-info.yaml
   - .gitignore
   - .gitlab-ci.yml

4. Implementieren, testen, linten

5. Erster Commit + Push auf **main**:
   ```bash
   git add -A
   git commit -m "feat: initial project setup"
   git push -u origin main
   ```

6. Falls Feature-Branch gewünscht ($BRANCH gesetzt und != main):
   ```bash
   git checkout -b $BRANCH
   # weitere Implementierung
   git add -A
   git commit -m "feat: ..."
   git push -u origin $BRANCH
   glab mr create --fill --target-branch main
   ```

## Git-Konfiguration

Die Git-Credentials sind bereits konfiguriert (über Env-Variablen im Pod).
Nutze `git` und `glab` CLI direkt.

```bash
# Repo anlegen
glab repo create myproject --group ${ART_NAME}/playground --internal

# Push
git push -u origin main

# MR erstellen
glab mr create --fill --target-branch main
```

## Wichtig

- Neue Repos: IMMER auf **main** Branch initial committen
- IMMER README.md mit Beschreibung anlegen
- IMMER pushen am Ende – Code der nur lokal liegt ist wertlos
- IMMER Merge Request erstellen wenn auf Feature-Branch
- Repo-URL und Branch kommen als Env-Variablen: $REPO_URL, $BRANCH
- GitLab Host ist IMMER: https://git.tech.rz.db.de

## Projektnamen

- Saubere, sprechende Namen verwenden (z.B. `hello-spring-boot`, `user-service`)
- KEINE Session-IDs, Job-IDs oder UUIDs im Projektnamen
- KEINE Suffixe wie `-4b98bbd1` oder `-abc123`
- Kebab-Case: `mein-projekt-name`
- Wenn repo_url angegeben: Projektnamen daraus ableiten
- Wenn nur gitlab_group angegeben: Projektnamen aus der Aufgabe ableiten

## Namenskorrektur

Falls die übergebene `repo_url` oder der Projektname eine Session-ID, Job-ID oder UUID enthält (z.B. `hello-spring-4b98bbd1`, `my-app-abc4a303`):
- Den Suffix entfernen
- Nur den sauberen Projektnamen verwenden
- Beispiel: `hello-world-spring-boot-4b98bbd1` → `hello-world-spring-boot`

## Abschluss: Badges und Fertigmeldung

### GitLab Projekt-Badges anlegen

Erst prüfen ob Badges schon existieren, dann nur fehlende anlegen:

```bash
# Bestehende Badges prüfen
EXISTING=$(glab api "projects/:id/badges" | python3 -c "import sys,json; print([b["name"] for b in json.load(sys.stdin)])")

# Pipeline Badge (wenn nicht vorhanden)
if ! echo "$EXISTING" | grep -q "Pipeline"; then
  glab api -X POST "projects/:id/badges" -f "link_url=https://git.tech.rz.db.de/%{project_path}/-/pipelines" -f "image_url=https://git.tech.rz.db.de/%{project_path}/badges/%{default_branch}/pipeline.svg" -f "name=Pipeline"
fi

# Coverage Badge
if ! echo "$EXISTING" | grep -q "Coverage"; then
  glab api -X POST "projects/:id/badges" -f "link_url=https://git.tech.rz.db.de/%{project_path}/-/pipelines" -f "image_url=https://git.tech.rz.db.de/%{project_path}/badges/%{default_branch}/coverage.svg" -f "name=Coverage"
fi

# Web-Endpoint / Landing-Page Badge (wenn deployed)
if ! echo "$EXISTING" | grep -q "App"; then
  glab api -X POST "projects/:id/badges" -f "link_url=https://{app-name}-{namespace}.${ART_NAME}-iat.cnp-test.comp.db.de" -f "image_url=https://img.shields.io/badge/App-live-green" -f "name=App"
fi
```

Regeln:
- Keine doppelten Badges anlegen (erst prüfen)
- Jeder Web-Endpoint/Landing-Page bekommt ein Badge mit der URL
- Preview-Umgebung: Badge mit Preview-URL
- Prod-Umgebung: Badge mit Prod-URL

### Fertigmeldung

Wenn alles abgeschlossen ist:
```bash
echo "PROGRESS: 100% - Fertig: MR erstellt, Pipeline grün, Badges gesetzt"
```

## Aufgabe abschließen

Wenn alles fertig ist (MR gemerged, Main-Pipeline grün, Issues geschlossen):

```bash
echo "PROGRESS: 100% - Aufgabe abgeschlossen: MR gemerged, Pipeline grün, Issues geschlossen"
```

Erst PROGRESS 100% melden wenn:
- [ ] Alle Issues geschlossen
- [ ] MR gemerged
- [ ] Main-Pipeline grün
- [ ] Keine offenen Findings

Wenn Main-Pipeline failed → NICHT 100% melden, sondern fixen.