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