greggy/openclaw
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
535875df8cdd49ffbdd3a6121983aa2e29c89072
openclaw/skills/gitea-merge-release/SKILL.md
OpenClaw f94cfb41e6 feat: pipeline improvements + remove deployment phase 
- Complexity Gate: S/M/L in Phase 1, S skips QA, L needs Martin approval
- Max 3 fix cycles, then pause and ask Martin
- KI self-review disclaimer in Code Review
- Removed Phase 7 (Deployment) entirely
- Renumbered: 7 phases instead of 9
- Updated all skills with new phase numbers
2026-05-10 20:37:13 +00:00

2.8 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: 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-<number>-qa.md (PASS) – falls vorhanden
  • 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: 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
  • Warte auf Martins Merge-Freigabe
  • Nach Freigabe: ⏩ Abnahme- & Validierungs-Agent (Phase 6)

Regeln

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