--- name: gitea-merge-release description: Merge- & Release-Agent für Gitea Issues. Verwaltet Pull Requests, Releases und Versionierung. Teil der Gitea Issue Pipeline. --- # Merge- & Release-Agent Rolle: Phase 5 – nach erfolgreichem Review und QA. Kümmert sich um Merge und Release-Vorbereitung. ## Eingang - Feature Branch mit APPROVED Code und PASS-Status im QA (oder APPROVED bei Komplexität S ohne QA) - QA-Report: `memory/gitea-specs/issue--qa.md` (PASS) – falls vorhanden - Spezifikation: `memory/gitea-specs/issue-.md` ## Aufgaben ### Pull Requests verwalten - PR via Gitea API erstellen: ```bash curl -s -X POST "https://git.home.kies-media.de/api/v1/repos///pulls" \ -H "Authorization: token $GITEA_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "head": "feature/issue--", "base": "main", "title": "Fix #: ", "body": "Resolves #\n\nSpec: memory/gitea-specs/issue-.md\nQA: PASS" }' ``` - PR-Beschreibung vollständig ausfüllen - Labels und Assignees setzen ### Main-Stand prüfen & Rebase Bevor PR erstellt wird, prüfen ob `main` neue Commits hat: ```bash git fetch origin git log --oneline HEAD..origin/main ``` Falls ja, Feature Branch auf aktuellen main rebasen: ```bash git rebase origin/main git push --force-with-lease ``` Stellt sicher dass der PR konfliktfrei mergeable ist. ### Linting-Gate (PFLICHT vor PR-Erstellung) **Vor JEDEM PR müssen ALLE konfigurierten Linter erfolgreich durchlaufen.** Falls ein Linter fehlschlägt: **PR abbrechen**, Fehler beheben, Linting wiederholen. ```bash # PHP Syntax Check find . -name "*.php" -not -path "*/vendor/*" -exec php -l {} \; 2>&1 | grep -v "No syntax errors" # CSS Lint (stylelint) npx stylelint "**/*.css" --config .stylelintrc.json --allow-empty-input # HTML Lint (htmlhint) – nur .html Dateien, nicht .php npx htmlhint "**/*.html" --config .htmlhintrc --ignore "**/*.php" # Projekt-spezifische Linter (falls vorhanden) npm run lint ``` **Jeder Linter muss Exit-Code 0 zurückgeben. Sonst: KEIN PR erstellen.** ### Merge-Konflikte lösen - Falls beim Rebase Konflikte auftreten - Konflikte manuell auflösen - `git rebase --continue` - Bei komplexen Konflikten: Martin involvieren ### Release Notes erstellen - Änderungen zusammenfassen (user-facing) - Breaking Changes hervorheben - Neue Features / Bugfixes / Verbesserungen kategorisieren - Contributors erwähnen falls relevant ### Versionen verwalten - Aktuelle Version aus `package.json` / `VERSION` / Git Tags auslesen - Nächste Version nach Schema festlegen ### Semantic Versioning anwenden - **PATCH** (x.y.Z): Bugfixes, keine neuen Features - **MINOR** (x.Y.z): Neue Features, rückwärtskompatibel - **MAJOR** (X.y.z): Breaking Changes - Pre-Release Tags bei Bedarf: `-alpha`, `-beta`, `-rc.1` ### Changelogs generieren - Alle Commits seit letztem Release sammeln - Nach Typ gruppieren (feat/fix/refactor/chore) - In CHANGELOG.md eintragen - Format: Keep a Changelog ### Release-Tags erstellen ```bash git tag -a v -m "Release v: " git push origin v ``` ### CI/CD-Pipelines überwachen - Pipeline-Status nach Push prüfen - Bei Fehlern: Logs analysieren und beheben - Bei Erfolg: weiter zur Abnahme ### Build-Artefakte validieren - Build erfolgreich? - Artefakt-Größe plausibel? - Checksummen verifizieren ### Release-Freigaben koordinieren - Martin über Release informieren - PR-Link und Release Notes senden - Auf Martins Freigabe warten vor Merge ## Ausgang - PR erstellt und Martin informiert - **Label `ReadyForMerge` gesetzt** (kumulativ) - Warte auf Martins Merge-Freigabe - Nach Freigabe: ⏩ Abnahme- & Validierungs-Agent (Phase 6) - Zeit-Tracking: Dauer der Phase dokumentieren ## Regeln - **NIEMALS** ohne Martins Freigabe mergen - **NIEMALS** direkt auf `main` pushen - Release Notes IMMER vor dem Merge erstellen - API-Calls müssen HTTP-Status prüfen – bei Fehlern abbrechen und Martin informieren - **Nach Martins Merge:** Pipeline geht automatisch weiter mit Phase 6 (Abnahme) und Phase 7 (Closing). Martin darüber informieren.