#Open-Claw an Jira andocken

1 messages · Page 1 of 1 (latest)

nimble rune
#

Ich wĂĽrde gerne meinen Programmier-Agenten (Prologus oder kurz P) mit Jira verbinden, sodass er meine Issues direkt bearbeiten kann, wenn ich sie ihm zu weise.
Was ist dabei zu tun bzw. zu berücksichtigen? Ist das "Out of the Box" möglich oder braucht es da irgenwie Skills, die man konfigurieren müsste? Ich verwende in meinem Projekt GitLab. Hat das auf eine etwaige Jira-Verwendung mit Prologus Einfluss?

robust kettleBOT
#

Kurz: nicht komplett “out of the box”, aber gut machbar.

FĂĽr Jira gilt aktuell eher derselbe Weg wie bei anderen externen SaaS-Integrationen: Custom Skill / Plugin / MCP, nicht native First-Class-Integration.

Was du brauchst

  1. Integrationsebene wählen
  • Robust: Jira per MCP-Server oder Plugin anbinden
  • Pragmatisch: Custom Skill, der Jira-API-Endpunkte nutzt
  • Nur Notlösung: Browser-Automation (fragiler)
  1. Trigger-Modell festlegen
  • Manuell: „Bearbeite JIRA-123“
  • Automatisch bei Zuweisung: Jira Automation/Webhook oder periodisches Polling (Cron), das P anstößt
  1. Berechtigungen sauber setzen
  • eigener Bot-User in Jira
#
  • minimale Scopes (lesen/kommentieren/transitionieren statt Admin)
  • gleiche Idee fĂĽr GitLab-Token
  1. Klare Arbeitsregeln in Skill/Prompt
  • z. B. erst analysieren, dann Status ändern, dann Kommentar posten
  • keine Massenupdates ohne explizite Bestätigung

Einfluss von GitLab auf Jira mit P?

Kein Blocker. Jira + GitLab funktioniert grundsätzlich parallel.
Aber praktisch gilt:

  • FĂĽr „Issue bearbeiten“ braucht P Jira-Zugriff
  • FĂĽr „Code ändern + MR erstellen“ braucht P GitLab-Zugriff
  • Am besten Issue-Key-Konventionen nutzen (PROJ-123 in Branch/Commit/MR), damit Jira/GitLab sauber verlinken

Wichtiger OpenClaw-Hinweis

#

Wenn du ACP/Bridge nutzt: per-session mcpServers werden nicht unterstützt — MCP muss auf Gateway/Agent-Ebene konfiguriert werden (nicht pro ACP-Session).

Docs dazu:

Wenn du willst, kann ich dir als Nächstes eine konkrete Minimal-Architektur skizzieren (Jira-Aktionen + GitLab-Aktionen + Trigger), die du 1:1 für Prologus übernehmen kannst.

nimble rune
#

ja ich hätte vielleicht eine Todo-Liste/check-Liste, bei der ich in Jira zunächst nur einen Issue P zuweise, dass ihn dann triggertdie Programmier- oder vielleicht auch Dokumentieraufgabe durchzuführen und dann am Ende einen MR zu erstellen um als Bonus auch den Jira-Issue auf Test zustellen.

robust kettleBOT
#

Perfekt — dafür ist ein MVP-Workflow super geeignet.
Hier ist eine praktische Checkliste, genau fĂĽr deinen Use Case:

âś… Zielbild (MVP)

Wenn du in Jira einen Issue an P zuweist, dann soll:

  1. P getriggert werden
  2. Aufgabe umsetzen (Code oder Doku)
  3. MR in GitLab erstellen
  4. Jira-Issue auf Test setzen (optional nur bei Erfolg)

🧩 Checkliste: Setup

1) Jira/GitLab-Bot-Identität

#
  • [ ] Eigener technischer User fĂĽr P in Jira
  • [ ] Eigener technischer User/Token fĂĽr GitLab
  • [ ] Least-Privilege-Rechte (nicht Admin)

2) Trigger definieren

  • [ ] Entscheiden: Webhook (sofort) oder Cron-Polling (einfacher)
  • [ ] Trigger nur fĂĽr relevante Projekte/Issue-Typen
  • [ ] Trigger nur wenn assignee == P

3) OpenClaw-Seite

  • [ ] P hat Zugriff auf nötige Tools (Coding + Jira-Integration)
  • [ ] Jira-Anbindung ĂĽber MCP/Plugin/Skill eingerichtet
  • [ ] Secrets sauber hinterlegt (nicht in Prompts/Repo)

4) Workflow-Regeln (sehr wichtig)

  • [ ] Branch-Name enthält Jira-Key (z. B. feature/PROJ-123-...)
  • [ ] MR-Titel enthält Jira-Key
#
  • [ ] P postet Fortschritt als Jira-Kommentar (Start / Ergebnis / MR-Link)
  • [ ] Jira-Transition auf Test nur wenn MR erfolgreich erstellt wurde

5) Idempotenz / Doppeltrigger vermeiden

  • [ ] Marker setzen (Label/Kommentar/Custom Field), dass Issue bereits verarbeitet wird
  • [ ] Bei erneutem Trigger: nicht nochmal von vorne starten
  • [ ] Fehlerfall: Kommentar + klarer Next Step statt still scheitern

🔄 Empfohlene Ablauf-Logik

  1. Zuweisung an P in Jira
  2. Trigger feuert (Webhook oder Polling erkennt es)
  3. P liest Issue + Akzeptanzkriterien
  4. P erstellt Branch in GitLab
  5. P implementiert / dokumentiert
#
  1. P erstellt MR
  2. P kommentiert im Jira-Issue mit MR-Link
  3. Wenn alles ok: Transition -> Test
  4. Wenn nicht ok: Status bleibt, Kommentar mit Blocker

⚠️ Was oft schiefgeht (und wie vermeiden)

  • Transition per Name statt ID → bricht bei Workflow-Ă„nderungen
    → [ ] Transition-ID stabil verwenden
  • Zu breite Berechtigungen → Sicherheitsrisiko
    → [ ] minimale Scopes
  • Kein Retry/Locking → doppelte MRs
    → [ ] dedupe + lock pro Issue-Key
  • “Test” heiĂźt in jedem Projekt anders
    → [ ] pro Projekt Mapping pflegen (Ready for Test, In QA, etc.)
#

📌 Bonus: “Done Definition” für Auto-Transition auf Test

Setze alle Bedingungen:

  • [ ] MR existiert
  • [ ] MR-Link wurde im Jira-Issue kommentiert
  • [ ] Mindestens 1 Commit referenziert den Jira-Key
  • [ ] (optional) CI grĂĽn

Nur dann -> Transition auf Test.

Wenn du willst, baue ich dir als nächsten Schritt eine konkrete Vorlage für:

  1. Jira Automation Rule (Trigger + Conditions + Action),
  2. P-Prompt/Skill-Text,
#
  1. klare Entscheidungsmatrix „wann auf Test setzen / wann nicht“.
nimble rune
#

ja bitte