Integrationen

Die meisten Teams, die auf fremforge umsteigen, haben bereits einen Issue-Tracker – Jira, Azure Boards, Linear, Trello – und wollen, dass ihre Codeänderungen auf die Tickets zurückverweisen, aus denen sie entstanden sind. Die Forgejo-Plattform, auf der fremforge aufbaut, bringt dafür einen externen Issue-Tracker als Baustein mit, der den einseitigen, anklickbaren Link ganz ohne Entwicklungsaufwand abdeckt: Hinterlege ein URL-Muster in den Repository-Einstellungen, und jedes JIRA-123 in einer Commit-Nachricht, einem Branch-Namen oder einem PR-Titel wird zu einem Link direkt in dein Jira (oder Azure DevOps, Linear oder die Trello-Karte).

Dieser Abschnitt ist die Anleitung für die sechs Tracker, nach denen am häufigsten gefragt wird. Jede Seite umfasst etwa 50 Zeilen und behandelt:

Die Forgejo-Seite: das URL-Muster, den regulären Ausdruck und die Felder der Repository-Einstellungen.
Die Tracker-Seite: den optionalen eingehenden Webhook (damit PR- und Commit-Benachrichtigungen auch in deinem Tracker erscheinen).
Konventionen für Commit-Nachrichten: die Syntax, mit der deine Entwicklerinnen und Entwickler den Link auslösen (z. B. [JIRA-123], AB#456, LINEAR-789).
Folgen für Unterauftragsverarbeiter: was es nach deinem fremforge-AVV bedeutet, wenn Commit-Metadaten eine Organisationsgrenze überschreiten.

Wähle deinen Tracker

Jira Cloud: von Atlassian gehostet (*.atlassian.net).
Jira Data Center: selbst gehostetes Jira in deiner Infrastruktur.
Azure Boards: der Tracker von Microsoft, Teil von Azure DevOps.
Linear: der Cloud-Tracker Linear.app.
Trello: der kartenbasierte Tracker von Atlassian.
Plane: selbst gehosteter Open-Source-Issue-Tracker (Apache 2.0).

Incident-Management

ServiceNow: ein ServiceNow-Incident für jedes Sicherheitsereignis (neuer kritischer Befund, Malware-Treffer, blockierter Pull, Richtlinienverstoß), über die Table API.

Was hier NICHT enthalten ist

Automatische Statusübergänge („JIRA-123 schließen, wenn der PR gemergt wird“): fremforge ändert den Status von Issues in deinem externen Tracker (noch) nicht automatisch. Der Link geht in eine Richtung: Commit/PR/Branch → Tracker. Die Gegenrichtung (die Tracker-Oberfläche zeigt verknüpfte Commits) kommt über den eingehenden Webhook, den jeder Tracker anbietet; richte ihn auf der Tracker-Seite nach den Anleitungen der einzelnen Seiten ein.
Synchronisierung benutzerdefinierter Felder: fremforge schreibt nicht in benutzerdefinierte Felder, Sprints, Epics oder Work-Item-Hierarchien des Trackers. Das sind trackerinterne Konzepte, die sich zu stark unterscheiden, um sie zu vereinheitlichen.

Hängt dein Ablauf davon ab, dass Issues beim Merge automatisch geschlossen werden, hast du zwei Möglichkeiten:

Automatisierung auf der Tracker-Seite: Jeder der oben genannten Tracker lässt sich so einrichten, dass er ein Issue schließt, wenn ein Webhook mit einem bestimmten Inhalt eintrifft. Verbinde den ausgehenden Webhook von fremforge (Admin → Webhooks) mit dem Automatisierungs-Endpunkt deines Trackers und lege die Schließregel dort an.
Eine Forgejo Action in deinem Repository: Füge einen Schritt hinzu, der bei pull_request.closed mit dem Filter merged: true per POST die REST-API deines Trackers aufruft. Eine Workflow-Datei mit fünf Zeilen. Möglicherweise liefern wir in einer künftigen Version eine Vorlage dafür aus; bis dahin baust du das selbst.

Unterauftragsverarbeiter

Wenn du Commit-Metadaten mit einem externen Tracker verknüpfst, fließen Commit-Nachrichten (und ihre Autorinnen und Autoren) in die Cloud dieses Trackers. Bei gehosteten Trackern entsteht dadurch nach deinem fremforge-AVV eine neue Beziehung zu einem Unterauftragsverarbeiter. Die Seiten zu den einzelnen Trackern nennen die jeweilige Steuerungsebene (USA / EU / hybrid), damit deine DSFA sie korrekt aufführen kann.

Selbst gehostete Tracker (Jira DC, Plane) sind keine Unterauftragsverarbeiter: Die Metadaten bleiben innerhalb deines eigenen Perimeters.