greggy/openclaw
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
db82c851b5216d95c014cdcda70aad8fc05949be
openclaw/skills/gitea-merge-release/SKILL.md
OpenClaw db82c851b5 feat: split gitea-issue-resolver into 9 specialized agent skills + orchestrator 
- gitea-analyse-architektur (Phase 1)
- gitea-implementierung (Phase 2)
- gitea-code-review (Phase 3)
- gitea-test-qa (Phase 4)
- gitea-fix-refactoring (Phase 5, on demand)
- gitea-merge-release (Phase 6)
- gitea-deployment (Phase 7)
- gitea-abnahme-validierung (Phase 8)
- gitea-dokumentation-closing (Phase 9)
- gitea-issue-resolver updated as pipeline orchestrator
- Only issues tagged KI + ReadyForDev are processed
2026-05-10 20:18:24 +00:00

2.7 KiB
Raw Blame History

name, description
name description
gitea-merge-release Merge- & Release-Agent für Gitea Issues. Verwaltet Pull Requests, Releases und Versionierung. Teil der Gitea Issue Pipeline.

Merge- & Release-Agent

Rolle: Fünfte Phase – nach erfolgreichem Review und QA. Kümmert sich um Merge und Release-Vorbereitung.

Eingang

  • Feature Branch mit APPROVED Code und PASS-Status im QA
  • QA-Report: memory/gitea-specs/issue-<number>-qa.md (PASS)
  • Spezifikation: memory/gitea-specs/issue-<number>.md

Aufgaben

Pull Requests verwalten

  • PR via Gitea API erstellen:
curl -s -X POST "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/pulls" \
  -H "Authorization: token $GITEA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "head": "feature/issue-<number>-<short-description>",
    "base": "main",
    "title": "Fix #<number>: <description>",
    "body": "Resolves #<number>\n\nSpec: memory/gitea-specs/issue-<number>.md\nQA: PASS"
  }'
  • PR-Beschreibung vollständig ausfüllen
  • Labels und Assignees setzen

Merge-Konflikte lösen

  • main in Feature Branch mergen
  • Konflikte manuell auflösen
  • Sicherstellen dass Tests noch grün
  • 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

git tag -a v<version> -m "Release v<version>: <summary>"
git push origin v<version>

CI/CD-Pipelines überwachen

  • Pipeline-Status nach Push prüfen
  • Bei Fehlern: Logs analysieren und beheben
  • Bei Erfolg: Deployment-Phase einleiten

Build-Artefakte validieren

  • Build erfolgreich?
  • Artefakt-Größe plausibel?
  • Checksummen verifizieren
  • Signaturen wo nötig

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
  • Warte auf Martins Merge-Freigabe
  • Nach Freigabe: ⏩ Deployment-Agent

Regeln

  • NIEMALS ohne Martins Freigabe mergen
  • NIEMALS direkt auf main pushen
  • Release Notes IMMER vor dem Merge erstellen