Git-Integrationen

Anbinden

Verwaltung, Integrationen. Drei Anbieter:

• GitLab, selbst gehostet oder gitlab.com: ein Token mit read_api; ein Gruppentoken überlebt es, wenn eine Person geht
• GitHub, github.com oder GitHub Enterprise Server: ein feingranulares Token mit Leserecht auf Contents, Pull requests, Actions, Deployments und Metadata, oder ein klassisches Token mit repo
• Bitbucket Cloud: ein Zugriffstoken des Workspace, des Projekts oder des Repositorys mit Leserechten, oder das API-Token eines Kontos zusammen mit dessen E-Mail

Legen Sie eine Verbindung an mit einem Namen, der Serveradresse (ohne Pfad), der Gruppe, Organisation oder dem Workspace, den sie abdeckt, dem Token und dem Synchronisierungsintervall (Standard 60 Minuten). Token werden verschlüsselt gespeichert und nie wieder gezeigt. Testen prüft die Verbindung; Synchronisieren liest sie sofort. Eine neue Verbindung wird ausgeschaltet gespeichert; solange sie nicht auf Ein steht, wird nichts gelesen und nichts empfangen.

Wie Arbeitselemente gefunden werden

Nennen Sie den Schlüssel des Arbeitselements im Branch-Namen, in der Commit-Nachricht oder im Titel des Merge Requests, zum Beispiel feature/PAY-12-login. Schlüssel werden unabhängig von Groß- und Kleinschreibung erkannt, müssen für sich stehen und verknüpfen nur mit Arbeitselementen, die es gibt. Der Abschnitt Entwicklung des Arbeitselements zeigt die Branches, Commits, Merge- oder Pull Requests, Builds und Deployments; Verknüpfungen lassen sich auch von Hand hinzufügen.

Webhooks

Die Synchronisierung nach Zeitplan ist der Rückfallweg. Für Ereignisse innerhalb von Sekunden geben Sie an der Verbindung ein Geheimnis aus und tragen im Git-Server einen Webhook mit der angezeigten Webhook-Adresse ein (unter /api/webhooks/dev/):

• GitLab: das Geheimnis in "Secret token" einfügen und Push, Merge request, Pipeline und Deployment events ankreuzen. GitLab-Versionen, die stattdessen einen Signierungstoken erzeugen, können ihn in "Signing token" einfügen; der signierte Zeitstempel verhindert Wiedereinspielungen
• GitHub: Content-Type application/json, das Geheimnis sowie Pushes, Pull requests, Pull request reviews, Workflow runs und Deployment statuses. Der Körper wird mit HMAC-SHA256 signiert
• Bitbucket: das Geheimnis sowie Repository Push, Build status created und updated und die Pull-Request-Ereignisse. Für Deployments sendet Bitbucket keinen Webhook; sie werden bei jeder Synchronisierung gelesen

Signaturen und Geheimnisse werden in konstanter Zeit verglichen. Builds und Deployments, deren Ausgang nie gemeldet wurde, werden bei jeder Synchronisierung erneut abgefragt, und die geplante Synchronisierung holt alles Weitere nach, was ein Webhook verpasst hat.

Arbeit mit Entwicklungsereignissen bewegen

Ein Workflow-Auslöser ist eine Regel an einem Übergang: wenn ein Branch angelegt wird, ein Commit eintrifft, ein Merge- oder Pull Request geöffnet, zusammengeführt oder abgelehnt wird, ein Build besteht oder fehlschlägt oder die Arbeit deployt wird, geht das Arbeitselement diesen Pfeil entlang. Er erfindet nie einen Statuswechsel: steht das Element nicht dort, wo der Pfeil beginnt, bewegt sich nichts. Auch Automatisierungsregeln können auf Entwicklungsereignisse reagieren.