Modul · setzt Aufgabenboards voraus
Enclessa verbindet sich mit GitHub, macht aus Issues und Pull Requests Karten auf einem Aufgabenboard und hält beide Seiten in beide Richtungen synchron. Ein Pull Request, der ein Issue schließt, hängt sich an die Karte dieses Issues, statt eine zweite Karte zu werden; Check-Rollup und Review-Entscheidung stehen auf der Karte, und die Spalten des Boards werden auf ein Status-Feld von GitHub Projects v2 abgebildet. Änderungen nach GitHub zurückzuschreiben ist eine Einstellung, die eine Organisation bewusst einschaltet; ist sie aus, liest der Connector nur und schreibt nie.
Aktualisiert
- Richtung
- GitHub nach Enclessa immer; zurück zu GitHub nur nach Einschalten
- Was synchronisiert wird
- Issues, Pull Requests, Projects-v2-Status, Checks, Reviews
- Kartenverknüpfung
- Ein Pull Request hängt sich an die Karte des Issues, das er schließt
- Hosts
- GitHub.com und GitHub Enterprise Server
- Authentifizierung
- Eine GitHub App oder ein persönliches Zugriffstoken, versiegelt gespeichert
- Voraussetzung
- Das Modul Aufgabenboards
Wie funktioniert die Verbindung zu GitHub?
Sie besteht aus drei Ebenen, und dass diese getrennt bleiben, verhindert, dass ein unbedachter Klick eine ganze Organisation neu verdrahtet. Eine Administratorin richtet pro Organisation eine Verbindung ein, entweder über eine GitHub App oder ein persönliches Zugriffstoken. Wer Boards verwalten darf, verknüpft dann ein Board mit einem Repository, einem Projects-v2-Projekt oder beidem. Von da an trägt jede Karte ihre eigene Referenz auf das Issue, den Pull Request oder das Projekt-Element, für das sie steht.
- Eine Verbindung pro Organisation, eingerichtet von einer Administratorin
- Eine Verknüpfung pro Board, geschützt durch die Berechtigung, die ohnehin für Boards gilt
- Eine Referenz pro Karte, geschützt durch die Berechtigung, die ohnehin für Karten gilt
- GitHub Enterprise Server wird unterstützt, indem API-Host und Web-Host getrennt gespeichert werden
- Zugangsdaten werden vor dem Speichern mit AES-256-GCM verschlüsselt und nie im Klartext gehalten
Was geht tatsächlich zwischen GitHub und dem Board hin und her?
Issues und Pull Requests kommen als Board-Einträge an. Die Spalten des Boards werden auf das Status-Feld eines GitHub-Projects-v2-Projekts abgebildet, sodass das Verschieben einer Karte und das Verschieben eines Projekt-Elements dasselbe bedeuten. Jede Karte speichert zwischen, worauf sie zeigt — den Zustand, die Review-Entscheidung und das Check-Rollup —, sodass eine Reviewerin sieht, dass der Build rot ist, ohne einen weiteren Tab zu öffnen.
- Issues hinein, Karten heraus, synchron gehalten, egal welche Seite sich ändert
- Ein Pull Request, der ein Issue schließt, hängt sich an die Karte dieses Issues
- Zuordnung von Spalte zu Projects-v2-Status-Feld, einmal pro Board festgelegt
- Check-Rollup und Review-Entscheidung werden auf der Karte zwischengespeichert
- Eine Karte kann aus Enclessa heraus als neues GitHub-Issue angelegt werden
Was verhindert, dass versehentlich ins Repository geschrieben wird?
Eine Einstellung namens „Änderungen nach GitHub zurückschreiben“, über die die Organisation entscheidet. Ist sie aus, hört eine Verknüpfung, die eine verschobene Karte nach GitHub übertragen würde, auf zu schreiben und liest weiter. Sie ist die erste Moduleinstellung, die die Plattform tatsächlich zur Laufzeit auswertet — und es gibt sie, weil niemand einen Connector behält, der stillschweigend anfängt, ein Repository zu bearbeiten, nur weil jemand ein Board aufgeräumt hat.
- Das Zurückschreiben ist eine Einstellung der Organisation, keine Gewohnheit einzelner Personen
- Ist sie aus, ist der Connector schreibgeschützt und sagt das auch
- Jede eingehende Zustellung wird per Signatur geprüft, bevor auf sie reagiert wird
- Zustellungen werden erfasst, bevor sie angewendet werden, und eine wiederholte Zustellungs-ID bewirkt nichts
- Die Konsole zeigt ein Zustellungsprotokoll, sodass sich ein fehlendes Update nachvollziehen lässt
Auf welche GitHub-Ereignisse hört der Connector?
Auf eine geschlossene Menge von sechs, ausgewählt statt angesammelt: Issues, Issue-Kommentare, Pull Requests, Pull-Request-Reviews, Änderungen an Projects-v2-Elementen und Check-Suites. Alles andere, was ankommt, wird als ignoriert erfasst, statt halb verarbeitet zu werden. Zustellungen werden pro Installation einzeln nacheinander angewendet, weil die sekundären Ratengrenzen von GitHub Parallelität aus einer einzelnen Installation härter bestrafen als Volumen.
- issues, issue_comment, pull_request, pull_request_review, projects_v2_item, check_suite
- Unbekannte Ereignisse werden als ignoriert erfasst, nicht erraten
- Strikt der Reihe nach pro Installation angewendet, um innerhalb der Ratengrenzen von GitHub zu bleiben
- Erfasste Zustellungen werden nach einer Woche gelöscht
Was es nicht leistet
Hier gesagt, statt erst nach der Anmeldung entdeckt.
- Der GitHub-Connector setzt das Modul Aufgabenboards voraus, weil das, was er synchronisiert, Board-Karten sind. Wer Boards ausschaltet, schaltet GitHub mit aus, und GitHub vor den Boards wieder einzuschalten wird abgelehnt.
- Nur GitHub. Es gibt keinen Connector für GitLab, Bitbucket, Azure DevOps oder Gitea, und keiner wird versprochen.
- Enclessa hostet keinen Code, führt keine Pipelines aus und prüft keine Diffs. Es zeigt Ihnen den Stand von Arbeit, die in GitHub liegt; die Arbeit bleibt in GitHub.
- Das Zurückschreiben umfasst die Felder, die der Sync verantwortet — den Status und das Issue, als das eine Karte angelegt wurde. Es ist kein allgemeiner Repository-Editor.
- Der Connector arbeitet mit verwalteten Räumen und deren Boards. Ende-zu-Ende-verschlüsselte Räume haben keinen serverseitigen Schlüssel, also kann nichts auf dem Server in ihnen lesen oder posten.
Verwandte Seiten
Fragen
- Ja. Das GitHub-Modul macht aus Issues und Pull Requests Karten auf einem Enclessa-Aufgabenboard und hält sie synchron. Ein Pull Request, der ein Issue schließt, hängt sich an die Karte dieses Issues, und Check-Rollup und Review-Entscheidung werden auf der Karte angezeigt.
- Nur, wenn die Organisation das Zurückschreiben einschaltet. Es ist eine Einstellung pro Organisation; ist sie aus, liest der Connector aus GitHub und schreibt nie dorthin, sodass das Verschieben einer Karte kein Repository verändern kann.
- Ja. Eine Verbindung speichert API-Host und Web-Host getrennt, weil sich bei GitHub Enterprise Server das eine nicht aus dem anderen ableiten lässt. Die Authentifizierung erfolgt entweder über eine GitHub App oder über ein persönliches Zugriffstoken.
- Ja. Der GitHub-Connector synchronisiert auf Board-Karten, also setzt er das Board-Modul voraus. Sind Boards für die Organisation ausgeschaltet, antwortet jede GitHub-Route mit 404, statt halb zu funktionieren.
- Nein. GitHub ist der einzige Connector für Quellcodeverwaltung, den es gibt, und es gibt keinen Connector für Jira, Linear, GitLab oder Bitbucket. Alles andere, was Sie anbinden wollen, läuft über eingehende Webhooks, Slash-Befehle oder die API.
Legen Sie in ein paar Minuten einen Workspace an. Er gehört Ihnen, erreichbar unter your-team.enclessa.app, betrieben in der Europäischen Union, mit Ende-zu-Ende-verschlüsselten Direktnachrichten ab der ersten.