Files

T

ankn a5f8fb49ab Migrate all repos into monorepo context folders

Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
      Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
      Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)

Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.

2026-06-30 20:39:52 +02:00

2.4 KiB

Raw Blame History

Quality Gates (Pflicht vor jedem Commit)

Reihenfolge vor dem Commit

Alle Checks MÜSSEN lokal bestehen bevor committed wird:

1. Linter (je nach Stack)

# Java
./mvnw checkstyle:check

# Python
ruff check .
ruff format --check .

# Go
golangci-lint run

# Node/TypeScript
npm run lint

# Shell-Scripts
shellcheck *.sh

# YAML
yamllint .

# Dockerfile
hadolint Dockerfile

2. Tests

# Java
./mvnw test

# Python
pytest -v --cov --cov-fail-under=80

# Go
go test ./... -cover

# Node
npm test

3. Security-Scans

# Secrets im Code suchen
gitleaks detect --source . --no-git

# Dependency-Vulnerabilities (Filesystem)
trivy fs --severity HIGH,CRITICAL .

# Docker-Image scannen (wenn Dockerfile vorhanden)
docker build -t app:scan .
trivy image --severity HIGH,CRITICAL app:scan

4. Erst dann committen

Nur wenn ALLE Checks grün sind:

git add -A
git commit -m "feat(scope): beschreibung (#issue)"

Bei Findings

Linter-Fehler: Sofort fixen
Test-Failures: Code korrigieren bis grün
Trivy HIGH/CRITICAL: Dependency updaten oder begründen (ADR)
Gitleaks: Secret entfernen, .gitignore anpassen

Verfügbare Tools im Container

Alle vorinstalliert – keine Installation nötig:

trivy – Container/Filesystem/Dependency Scanner
gitleaks – Secret Detection
golangci-lint – Go Linter
ruff – Python Linter/Formatter
hadolint – Dockerfile Linter
shellcheck – Shell Script Linter
yamllint – YAML Linter

Renovate-MRs prüfen (vor Dependency-Änderungen)

BEVOR du manuell Dependencies aktualisierst oder Vulnerabilities fixst:

# Offene Renovate-MRs im Projekt prüfen
GITLAB_HOST=git.tech.rz.db.de glab mr list --author=renovate-bot --state=opened

Wenn Renovate bereits einen MR für die betroffene Dependency hat:

Nicht selbst fixen – Renovate-MR nutzen
Pipeline des Renovate-MR prüfen
Bei grüner Pipeline: Approve + Merge
Bei fehlgeschlagener Pipeline: Retry oder manuell fixen und in den Renovate-Branch pushen

Warum?

Renovate trackt Versionen zentral
Doppelte Updates führen zu Merge-Konflikten
Renovate erstellt saubere Changelogs
Renovate-MRs sind bereits getestet

Nur manuell fixen wenn:

Kein Renovate-MR existiert
Renovate-MR ist seit >7 Tagen offen und blockiert
Renovate kann die Vulnerability nicht lösen (z.B. Major-Version-Sprung nötig)

2.4 KiB Raw Blame History Unescape Escape