DokumentationWorkflowsApps und Services
GitHub Releases Node
Veröffentlichte Versionen eines Repositorys: auflisten, lesen, anlegen, ändern oder löschen, mit automatisch erzeugter Änderungsliste. Hier findest du Einrichtung, Felder, Ein- und Ausgaben, Testablauf und Fehlerbehebung.
9 Min LesezeitAktualisiert am
Was GitHub Releases macht
Veröffentlichte Versionen eines Repositorys: auflisten, lesen, anlegen, ändern oder löschen, mit automatisch erzeugter Änderungsliste.
- 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 Releases“ ü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.
- Releases auflisten
- Release lesen
- Neuestes Release
- Release zum Tag
- Release anlegen
- Release ändern
- Release löschen
- Änderungsliste erzeugen
Einstellungen
| Feld | Bedeutung | Bereich |
|---|---|---|
| Aktion | Auswahl: Releases auflisten, Release lesen, Neuestes Release, Release zum Tag, Release anlegen, Release ändern, Release löschen, Änderungsliste erzeugen | 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 |
| 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 |
| Release-ID | Wird im Node-Panel konfiguriert. | Standard |
| Tag | Name der Version, z.B. v1.2.0. | Standard |
| Ausgangspunkt | Branch oder Commit für ein neues Tag. Leer: der Standard-Branch. | Erweitert |
| Titel | Wird im Node-Panel konfiguriert. | Standard |
| Beschreibung | Was neu ist. Markdown wird unterstützt. | Standard |
| Als Entwurf | Wird im Node-Panel konfiguriert. | Erweitert |
| Als Vorabversion | Wird im Node-Panel konfiguriert. | Erweitert |
| Beschreibung automatisch erzeugen | Wird im Node-Panel konfiguriert. | Erweitert |
| Entwurf | Auswahl: Nicht ändern, Ja, Nein | Erweitert |
| Vorabversion | Auswahl: Nicht ändern, Ja, Nein | Erweitert |
| Vorheriges Tag | Leer: das letzte Release. | Erweitert |
| 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
Neuestes Release lesen: 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"
}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: Releases auflisten, Release lesen, Neuestes Release, Release zum Tag, Änderungsliste erzeugen. Diese Aktionen brauchen „Änderungen erlauben“: Release anlegen, Release ändern, Release löschen.
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.