Automatisieren mit GitHub

Mit „Automatisieren mit GitHub“ kannst du Regeln erstellen, die auf Aktivitäten in deinen GitHub-Repositories reagieren und selbst Aktionen auf GitHub ausführen — ganz ohne Skripte. Das ist ideal für alle, die Infrastruktur oder Incident-Workflows gemeinsam mit einem GitHub-basierten Entwicklungsteam verwalten.

Übersicht

• Löse Automatisierungen durch GitHub-Ereignisse wie Workflow-Läufe, Issues, Pull Requests, Pushes, Releases und Deployments aus
• Führe automatisch Aktionen auf GitHub aus — erstelle Issues, merge Pull Requests, löse Workflows aus, setze den Commit-Status und mehr
• Kombiniere GitHub mit dem Rest von InfraNest, zum Beispiel indem bei Beginn eines Vorfalls automatisch ein GitHub-Issue geöffnet wird

Bevor du beginnst

1. Gehe zu Integrationen und verbinde dein GitHub-Konto.
2. Um GitHub-Auslöser zu nutzen (die Seite Wenn das passiert einer Regel), benötigst du die installierte InfraNest Automations-App — eine Token-Verbindung kann nur GitHub-Aktionen ausführen, aber nicht durch GitHub-Ereignisse ausgelöst werden.
3. Im Automatisierungs-Editor erscheinen GitHub-Auslöser und -Aktionen gemeinsam unter der Gruppe GitHub.
4. Wenn du einen GitHub-Auslöser wählst, bevor du verbunden bist, erinnert dich InfraNest daran, zuerst die Verbindung herzustellen.

Auf GitHub-Aktivität reagieren (Auslöser)

1. Starte eine neue Automatisierung und wähle unter Wenn das passiert einen GitHub-Auslöser — zum Beispiel GitHub-Workflow-Lauf, GitHub-Issue, GitHub-Pull-Request, GitHub-Push, GitHub-Release, GitHub-Deployment, GitHub-Deployment-Status, GitHub-Commit-Status oder GitHub-Check-Run.
2. Füge Nur wenn-Filter hinzu, um die Auswahl einzugrenzen — zum Beispiel nur den Branch, nur ein bestimmtes Repository, nur Fehlschläge oder nur deine Organisation. Die Felder Repository und Konto schlagen beim Tippen deine verbundenen Repositories und Konten vor.
3. Beachte ein paar Besonderheiten bei den Filtern:
   • GitHub-Push-Ereignisse umfassen auch Tags und gelöschte Branches — filtere nach Branch und Gelöscht, um nur auf neue Commits zu reagieren.
   • GitHub-Kommentar (Issue oder PR) löst sowohl bei Issues als auch bei Pull Requests aus — filtere mit Bei einem Pull Request, um eines davon auszuwählen.
   • GitHub-Release löst dreimal pro Release aus. Füge „Aktion ist gleich published“ hinzufügen hinzu, damit deine Regel nur einmal läuft — der Editor bietet an, dies automatisch für dich zu erledigen.
   • Zugewiesen an (alle) trifft bei jedem Issue-Ereignis zu; Zuständige Person trifft nur auf die Person zu, die gerade zugewiesen oder entfernt wurde.
   • Produktionsumgebung unterscheidet ein Produktions-Deployment von einem Preview-Deployment.
   • Versuch (1 = erster Lauf) zählt Workflow-Wiederholungen — 1 ist der erste Lauf.
   • Abklingzeit gilt pro Issue, Workflow, Commit oder Deployment — eine Abklingzeit für ein Repository blockiert nie ein anderes.

Auf GitHub reagieren (Aktionen)

1. Wähle unter Das tun die Option Aktion hinzufügen und wähle eine GitHub-Aktion, wie GitHub-Workflow auslösen, GitHub-Workflow erneut ausführen, Fehlgeschlagene Jobs erneut ausführen, GitHub-Run abbrechen, GitHub-Issue erstellen, GitHub-Issue kommentieren, GitHub-Issue aktualisieren, GitHub-Issue schließen, GitHub-Issue erneut öffnen, Labels hinzufügen, Label entfernen, GitHub-Issue zuweisen, Pull Request mergen, PR-Review anfordern, GitHub-Deployment erstellen, Deployment-Status setzen, GitHub-Release erstellen oder Commit-Status setzen.
2. Wähle aus, welche GitHub-Verbindung die Aktion ausführen soll. Wenn du nur eine hast, wird sie automatisch gewählt.
3. Fülle Felder wie Repository (owner/repo), Workflow-Datei oder -ID, Branch, Umgebung, Labels (kommagetrennt), Zuständige (kommagetrennt) und Reviewer aus — diese bieten eine durchsuchbare Liste aus deinem verbundenen GitHub, oder du kannst einen Wert eingeben oder einen Platzhalter aus dem Auslöser einfügen.
4. Wenn eine Liste nicht lädt, prüfe die Meldung unter dem Feld:
   • Die Verbindung muss erneut hergestellt werden — stelle sie unter Integrationen wieder her.
   • Die GitHub App ist gesperrt — hebe die Sperre auf GitHub unter Settings → GitHub Apps → Configure auf.
   • Sie darf diese Liste nicht lesen — erteile die Berechtigung auf GitHub.
   • Sie kann dieses Repository nicht sehen — füge das Repository dem Zugriff der App auf GitHub hinzu oder verwende ein Token, das darauf zugreifen kann.
   • GitHub war gerade nicht erreichbar — versuche es in Kürze erneut.

Mit einer vorgefertigten Automatisierung starten

1. Öffne GitHub unter Integrationen und suche nach Vorgefertigte Automatisierungen, oder gehe zu Automatisierungen und öffne Vorlagenbibliothek.
2. Wähle Verwenden bei einer Vorlage, lege das Repository oder die Statusseite fest, mit der sie arbeiten soll, und wähle Automatisierung speichern.

Nützliche vorgefertigte Automatisierungen, die GitHub mit dem Rest deiner Umgebung verbinden:

• Vorfall geöffnet → GitHub-Issue öffnen, kombiniert mit Vorfall behoben → zugehöriges GitHub-Issue schließen, sodass Issues sich automatisch selbst nachverfolgen und schließen.
• Zertifikat läuft ab → GitHub-Issue öffnen, zwei Wochen im Voraus.
• Domain läuft ab → GitHub-Issue öffnen, einen Monat im Voraus.
• Release veröffentlicht → auf Statusseite ankündigen, nur für vollständige Releases (Vorabversionen werden übersprungen).
• GitHub-Workflow fehlgeschlagen → fehlgeschlagene Jobs einmal erneut ausführen — ein instabiler Job erhält einen erneuten Versuch, danach bleibt es dir überlassen.
• Deployment erfolgreich → Verfügbarkeit prüfen → Commit-Status setzen — InfraNest prüft deine Umgebung direkt nachdem GitHub das Deployment meldet, und markiert den Commit entsprechend. Diese Prüfung wirkt sich nicht auf die Monitor-Verfügbarkeit oder offene Vorfälle aus.
• Deployment erfolgreich → Cloudflare-Cache leeren.
• Deployment erfolgreich → auf Statusseite ankündigen.
• GitHub-Workflow fehlgeschlagen → Issue öffnen & benachrichtigen, und Zertifikat läuft ab → GitHub-Workflow ausführen.

NoteDie drei Automatisierungen unter „Deployment erfolgreich“ wirken sich nur auf Produktions-Deployments aus, sodass Preview-Deployments keine Ankündigungen oder Cache-Leerungen auslösen.

Beispiele

1. SSL-Erneuerung fehlgeschlagen → GitHub-Issue erstellen, füge das Label infrastructure hinzu und setze Zuständige (kommagetrennt) auf dein DevOps-Team.
2. Vorfall behoben → GitHub-Issue kommentieren, dann GitHub-Issue schließen — unter Verwendung von Verknüpfte Einträge, um Issue-Nummer und Repository automatisch auszufüllen. Wurde für diesen Vorfall kein Issue geöffnet, wird der Schritt übersprungen.
3. GitHub-Pull-Request in einen Branch gemergt → GitHub-Workflow ausführen, dann Deployment-Status setzen.
4. Ein Produktions-Health-Check ist erfolgreich → Commit-Status setzen auf erfolgreich.
5. GitHub-Release veröffentlicht → Statusseiten-Ankündigung posten.

Gut zu wissen

• Ein GitHub-Auslöser löst erst aus, sobald GitHub verbunden ist und die App diesen Ereignistyp abonniert hat. Wenn ein Auslöser nie läuft, bitte deinen Administrator, die Ereignisabonnements der App zu prüfen.
• Automatisierungen, die du ausführst, lösen deine eigenen GitHub-Auslöser nicht erneut aus — so verhindert man, dass eine Regel endlos auf ihre eigenen Kommentare oder Labels reagiert.
• Wenn zwei InfraNest-Workspaces dasselbe GitHub-Konto verbinden, reagieren Automatisierungen in beiden auf dessen Ereignisse.
• Wenn ein Schritt etwas erstellt (wie ein Issue oder Deployment), können spätere Schritte derselben Regel dies automatisch wiederverwenden.
• Eine Review von einem Team anzufordern, erfordert eine Organisationsverbindung, keine persönliche.
• Manche Aktionen zeigen ein Pro-Abzeichen an und benötigen einen höheren Plan.

TipLasse das Feld für den Workflow-Branch leer, um den Standard-Branch des Repositorys zu verwenden — er muss nicht main heißen.

Fehlerbehebung

• „Pull Request mergen“ merged nur das, was die Regel gesehen hat. Wenn jemand nach der Genehmigung, die die Regel gestartet hat, neue Commits pusht, wird nichts gemergt, und der Lauf erklärt den Grund.
• Wiederholungen: Setze Bei vorübergehendem Fehler wiederholen, um einen GitHub-Ausfall, ein Timeout oder ein Rate-Limit automatisch erneut zu versuchen. Eine dauerhafte Ablehnung zeigt den von GitHub gemeldeten Grund im Laufverlauf an.
• Wenn ein späterer Schritt auf ein Issue verweist, das zuvor erstellt werden sollte (über Verknüpfte Einträge), aber keines erstellt wurde, wird dieser Schritt übersprungen statt als fehlgeschlagen markiert.