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:

   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:

   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:

   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):

   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.

# 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:

# 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:

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):

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.