DokumentationWorkflowsApps und Services
GitHub Pull Requests Node
Pull Requests in einem Repository: suchen, anzeigen, anlegen, prüfen oder mergen, z.B. automatisch einen Aufräum-Pull-Request aus einem Workflow heraus erzeugen und erst bei grünen Prüfungen übernehmen. Hier findest du Einrichtung, Felder, Ein- und Ausgaben, Testablauf und Fehlerbehebung.
12 Min LesezeitAktualisiert am
Was GitHub Pull Requests macht
Pull Requests in einem Repository: suchen, anzeigen, anlegen, prüfen oder mergen, z.B. automatisch einen Aufräum-Pull-Request aus einem Workflow heraus erzeugen und erst bei grünen Prüfungen übernehmen.
- Verarbeitet einen Eingang.
- Stellt einen Ausgang für weitere Schritte bereit.
- Wird als normaler Schritt in den Ablauf eingebunden.
Node einrichten
- 01Öffne einen Workflow und füge „GitHub Pull Requests“ über Bausteine hinzu.
- 02Falls dein GitHub-Konto noch nicht verbunden ist, verbinde es direkt im Node-Panel oder unter Konnektoren.
- 03Fülle die erforderlichen Felder aus. Werte aus vorherigen Schritten kannst du als Variable einsetzen.
- 04Nutze Testdaten oder starte einen Testlauf und prüfe die Ausgabe des Nodes.
- 05Verbinde den erfolgreichen Ausgang mit dem nächsten Schritt und aktiviere den Workflow erst nach einem vollständigen Probelauf.
Aktionen und Betriebsarten
Wähle im Feld „Aktion“ die gewünschte Funktion. Danach zeigt das Node-Panel nur die dafür relevanten Einstellungen.
- PRs auflisten
- PR lesen
- PR anlegen
- PR mergen
- Geänderte Dateien
- Commits des PRs
- PR ändern
- Branch aktualisieren
- Ist gemerged?
- Prüfung anfragen
- Prüfanfrage zurückziehen
- Prüfungen auflisten
- Prüfung abgeben
- Zeilenkommentare
- Zeile kommentieren
- Prüfstatus lesen
Einstellungen
| Feld | Bedeutung | Bereich |
|---|---|---|
| Aktion | Auswahl: PRs auflisten, PR lesen, PR anlegen, PR mergen, Geänderte Dateien, Commits des PRs, PR ändern, Branch aktualisieren, Ist gemerged?, Prüfung anfragen, Prüfanfrage zurückziehen, Prüfungen auflisten, Prüfung abgeben, Zeilenkommentare, Zeile kommentieren, Prüfstatus lesen | Standard |
| Inhaber (User oder Org) | Der GitHub-Name, dem das Repo gehört, z.B. anymize. | Standard |
| Repository | Name des Repositorys, z.B. hello-world. | Standard |
| Status | Auswahl: Offen, Geschlossen, Alle | Standard |
| Nur Ziel-Branch | Nur Pull Requests, die in diesen Branch gehen, z.B. main. | Erweitert |
| Nur Quell-Branch | Im Format inhaber:branch, z.B. anymize:feature/foo. | Erweitert |
| Sortierung | Auswahl: Zuletzt angelegt, Zuletzt geändert, Meiste Kommentare, Am längsten offen | Erweitert |
| Anzahl (max. 100) | Wie viele Einträge pro Abruf geladen werden. Mit „Alle Seiten laden“ ohne Wirkung, dann sind es immer 100 je Seite. | Standard |
| Alle Seiten laden | Lädt weitere Seiten nach, bis alles da ist, höchstens 1000 Einträge. | Erweitert |
| Seite | Ab welcher Seite geladen wird, z.B. die nächste Seite aus dem vorigen Abruf. Leer: die erste. Mit „Alle Seiten laden“ ohne Wirkung. | Erweitert |
| PR-Nr. | Wird im Node-Panel konfiguriert. | Standard |
| Titel | Wird im Node-Panel konfiguriert. | Standard |
| Quell-Branch (von) | Der Branch mit deinen Änderungen, z.B. feature/foo. | Standard |
| Ziel-Branch (nach) | Der Branch, in den übernommen wird, meist main. | Standard |
| Text | Beschreibung, Bewertung oder Kommentar. Markdown wird unterstützt. | Standard |
| Als Entwurf | Wird im Node-Panel konfiguriert. | Erweitert |
| Änderungen durch Betreuer erlauben | Wird im Node-Panel konfiguriert. | Erweitert |
| Geprüfter Stand (Commit) | Commit, der geprüft wurde. Hat sich der Pull Request seitdem geändert, passiert nichts. Leer: der aktuelle Stand. | Standard |
| Merge-Methode | Wie der PR zusammengeführt wird. Im Zweifel „Merge-Commit“ wählen. | Erweitert |
| Titel des Merge-Commits | Wird im Node-Panel konfiguriert. | Erweitert |
| Nachricht des Merge-Commits | Wird im Node-Panel konfiguriert. | Erweitert |
| Nur mit grünen Prüfungen | Aus: übernimmt auch, wenn Prüfungen fehlen oder fehlschlagen. | Erweitert |
| Neuer Status | Auswahl: Nicht ändern, Offen, Geschlossen | Standard |
| Neuer Ziel-Branch | Wird im Node-Panel konfiguriert. | Erweitert |
| Prüfende Personen | GitHub-Namen, mit Komma getrennt. | Standard |
| Prüfende Teams | Team-Kürzel, mit Komma getrennt. | Erweitert |
| Ergebnis | Bei „Änderungen verlangen“ und „Kommentieren“ ist ein Text nötig. | Standard |
| Datei | Pfad der Datei im Repository, z.B. src/index.ts. | Standard |
| Zeile | Wird im Node-Panel konfiguriert. | Standard |
| Seite | Neue Fassung (rechts) oder alte Fassung (links). | Erweitert |
| Commit | Leer: der aktuelle Stand des Pull Requests. | Erweitert |
| Branch oder Commit | Wird im Node-Panel konfiguriert. | Standard |
| GitHub-Konto | Leer lassen, dann nutzt der Schritt dein verbundenes GitHub-Konto. | Erweitert |
| Für jedes Item einzeln ausführen | Aus (Standard): der Node läuft einmal für den gesamten Input. An: bekommt er mehrere Items (z. B. aus „Liste aufteilen“), läuft er einmal PRO Item, und {{ $json }} ist dabei jeweils genau dieses Item. So arbeitest du eine Dateiliste Eintrag für Eintrag ab. | Erweitert |
| Wenn ein Item fehlschlägt | „Überspringen“ schreibt für das fehlgeschlagene Item ein `error`-Feld und verarbeitet die übrigen weiter, statt den ganzen Lauf an einer einzigen unlesbaren Datei scheitern zu lassen. | Erweitert |
| Pause zwischen Items (Millisekunden) | Wartezeit vor jedem Durchlauf außer dem ersten. 1000 = 1 Sekunde pro Item. Nützlich, wenn die Gegenstelle sonst dichtmacht. Maximal 300000 (5 Minuten). | Erweitert |
Eingaben und Ausgaben
| Eingabe | Bedeutung | Typ |
|---|---|---|
| Standard | Der Node übernimmt das vollständige Ergebnis des vorherigen Schritts. | JSON |
| Ausgabe | Bedeutung | Typ |
|---|---|---|
| Standard | Das Ergebnis steht dem nächsten Schritt als JSON zur Verfügung. | JSON |
Dieser Node kann Listen Item für Item verarbeiten. Fehlerbehandlung und Pause zwischen Items findest du in den erweiterten Einstellungen.
Beispiel und Testlauf
Offenen PR aus Workflow erstellen: Starte den Node zunächst mit einem kleinen, eindeutig erkennbaren Datensatz. Öffne danach die Ausgabe und verwende nur Felder, die dort tatsächlich vorhanden sind.
Beispiel für einen Testlauf
{
"owner": "octocat",
"repo": "hello-world",
"head": "feat/copilot-tools",
"base": "main",
"title": "Add Copilot Tools"
}Zugriff und Sicherheit
Der Node arbeitet mit deinem eigenen verbundenen GitHub-Konto. Er sieht und ändert nur, was dieses Konto darf. Prüfe beim Verbinden die angezeigten Berechtigungen. Außerdem muss der passende Bereich (Issues, Pull Requests, Repos) in den Einstellungen deiner GitHub-Verbindung unter Konnektoren eingeschaltet sein. Standardmäßig sind alle Bereiche an.
„Aktionen erlauben“ in den Einstellungen deiner GitHub-Verbindung unter Konnektoren gilt auch für diesen Node und wird bei jedem Lauf geprüft. Mit „Nur lesen“ oder „Lesen und Entwürfe“ laufen nur die lesenden Aktionen: PRs auflisten, PR lesen, Geänderte Dateien, Commits des PRs, Ist gemerged?, Prüfungen auflisten, Zeilenkommentare, Prüfstatus lesen. Diese Aktionen brauchen „Änderungen erlauben“: PR anlegen, PR mergen, PR ändern, Branch aktualisieren, Prüfung anfragen, Prüfanfrage zurückziehen, Prüfung abgeben, Zeile kommentieren.
Schlüssel und Zugangsdaten gehören in die Workflow-Secrets oder in deine verbundenen Konten. Trage sie nie als normalen Text in Workflow-Felder, Testdaten oder Beschreibungen ein.
Häufige Fehler beheben
- Keine Ausgabe: Prüfe den letzten Testlauf und ob der vorherige Node die erwarteten Felder geliefert hat.
- Variable bleibt leer: Öffne die Ausgabe des vorherigen Schritts und übernimm den Feldnamen aus den echten Testdaten.
- Verbindung abgelehnt: Verbinde den Dienst erneut und erteile nur die Berechtigungen, die dieser Schritt benötigt.
- Aktion gesperrt: Stell „Aktionen erlauben“ der Verbindung unter Konnektoren auf „Änderungen erlauben“ oder wähle eine lesende Aktion.
- Liste wird nur einmal verarbeitet: Aktiviere die Ausführung pro Item in den erweiterten Einstellungen.