Automatisieren mit GitHub

Mit „Automatisieren mit GitHub“ kannst du Regeln erstellen, die auf Aktivität in deinen Repositories reagieren und auf GitHub zurückwirken – ganz ohne Skripte. Das ist für alle gedacht, die Vorfälle, Deployments und Infrastruktur-Ereignisse mit ihrem GitHub-Workflow synchron halten möchten.

#Überblick

• Löse Automatisierungen durch GitHub-Ereignisse wie Workflow-Läufe, Issues, Pull Requests, Pushes, Releases und Deployments aus.
• Lass InfraNest auf GitHub zurückwirken: Issues öffnen, Pull Requests mergen, Workflows auslösen, Commit-Status setzen und mehr.
• Nutze fertige Automatisierungen, um GitHub in wenigen Klicks mit Vorfällen, Zertifikaten, Domains und deiner Statusseite zu verknüpfen.

NoteGitHub-Trigger benötigen die installierte InfraNest Automations App. Eine Verbindung, die nur mit einem Token hergestellt wurde, kann lediglich GitHub-Aktionen ausführen – sie kann keine Regel durch GitHub-Aktivität starten.

#GitHub verbinden, bevor du beginnst

1. Gehe zu Integrations und verbinde dein GitHub-Konto (siehe Connect GitHub).
2. Im Automatisierungs-Editor erscheinen GitHub-Trigger und -Aktionen gemeinsam unter der Gruppe GitHub.
3. Wählst du einen GitHub-Trigger, bevor du verbunden bist, erinnert dich InfraNest daran, zuerst eine Verbindung herzustellen.

#Auf GitHub-Aktivität reagieren (Trigger)

1. Starte eine neue Automatisierung und wähle unter When this happens einen GitHub-Trigger – zum Beispiel einen Workflow-Lauf, ein Issue, einen Pull Request, einen Push, ein Release, ein Deployment oder einen abgeschlossenen Check.
2. Füge Only if-Filter hinzu, um die Auswahl einzugrenzen, etwa auf einen bestimmten Branch, ein Repository oder nur Fehlschläge. Die Felder für Repository und Konto schlagen beim Tippen deine verbundenen Repositories vor.
3. Filtere bei Pushes auf Branch or tag und Deleted, wenn du nur neue Commits auf einem Branch willst, nicht gelöschte Branches oder Tags.
4. Filtere bei Kommentaren auf On a pull request, wenn du nur Pull-Request-Kommentare möchtest, da Issue- und PR-Kommentare auf dieselbe Weise eintreffen.
5. Füge bei Releases Action equals published hinzu, damit die Regel einmal pro Release statt dreimal läuft. Der Editor kann diesen Filter für dich hinzufügen.
6. Lege bei Bedarf eine Abklingzeit fest – sie gilt pro Issue, Workflow, Commit oder Deployment und hält nie ein anderes Repository zurück.

#Auf GitHub reagieren (Aktionen)

1. Wähle unter Do this Aktion hinzufügen und wähle eine GitHub-Aktion – zum Beispiel GitHub-Workflow auslösen, GitHub-Issue erstellen, Pull Request mergen, GitHub-Deployment erstellen, GitHub-Release erstellen oder Commit-Status setzen.
2. Wähle, welche GitHub-Verbindung die Aktion verwenden soll. Hast du nur eine, ist sie bereits ausgewählt.
3. Fülle Felder wie Repository, Workflow, Branch, Umgebung, Labels oder Zuständige aus – diese bieten eine durchsuchbare Liste aus deinem verbundenen GitHub, oder du kannst einen Wert eingeben oder einen Platzhalter aus dem Trigger einfügen.
4. Kann ein Feld seine Liste nicht laden, prüfe die Meldung darunter – sie sagt dir, ob du dich in Integrations erneut verbinden, die App auf GitHub wieder aktivieren, eine Berechtigung erteilen oder der App Zugriff auf dieses Repository geben musst.

#Vorfälle und Warnungen in GitHub-Issues umwandeln

1. Um für jeden Vorfall automatisch ein Issue zu öffnen, gehe zu Integrations → GitHub, öffne Connections & settings, schalte Issues for Incidents ein und wähle das Repository. Das Beheben des Vorfalls schließt das Issue; ein wiederkehrender Vorfall bei noch offenem Issue fügt stattdessen einen Kommentar hinzu, anstatt ein neues anzulegen.
2. Um einen einzelnen Vorfall oder eine Warnung von Hand in ein Issue umzuwandeln, öffne dessen ⋯-Menü (oder Create issue unter Follow-up auf der Seite eines Vorfalls), wähle Create a GitHub issue, wähle das Repository, prüfe What we send und erstelle es. Die Karte zeigt dann das Issue an, etwa infra#42 · Open.
3. Existiert bereits ein Issue, wähle Link an existing issue und füge dessen Adresse oder owner/repo#42 ein.
4. Findet der Dialog im gewählten Repository bereits ein passendes offenes Issue, bietet er Link that one instead an.
5. Ist das Issue geschlossen, das Problem aber nicht behoben, verwende Reopen infra#42 aus demselben Menü.

NoteRepositories mit deaktivierten Issues sowie archivierte Repositories werden nicht angeboten, da GitHub das Issue ablehnen würde.

#Mit einer fertigen Automatisierung starten

1. Öffne GitHub unter Integrations und schau unter Ready-made automations nach, oder gehe zu Automations → Templates.
2. Wähle Use bei der gewünschten Vorlage.
3. Wähle das Repository oder die Statusseite, die sie verwenden soll.
4. Wähle Automatisierung speichern.

Nützliche fertige Automatisierungen sind unter anderem:

• Incident opened → open a GitHub issue, kombiniert mit Incident resolved → close its GitHub issue, sodass Issues sich selbst verfolgen und schließen.
• Certificate expiring → open a GitHub issue, zwei Wochen vor Ablauf gesendet.
• Domain expiring → open a GitHub issue, einen Monat vor Ablauf gesendet.
• Release published → announce on status page, nur für vollständige Releases (nicht für Vorabversionen).
• GitHub workflow failed → re-run failed jobs once, damit ein unzuverlässiger Job einen zweiten Versuch bekommt, ohne endlose Wiederholungen.
• Deployment succeeded → check it is up → set commit status, das die Umgebung genau dann prüft, wenn GitHub das Deployment meldet, und den Commit je nach Ergebnis grün oder rot markiert.
• Deployment succeeded → purge the Cloudflare cache Pro, damit Besucher sofort den neuen Build sehen.
• Deployment succeeded → announce on status page.
• GitHub workflow failed → open an issue & alert.
• Certificate expiring → run a GitHub workflow.

Titel und Nachrichten in diesen Vorlagen sind mit Platzhaltern vorformuliert (wie Released: {{tag}}), die beim Ausführen der Automatisierung automatisch gefüllt werden. Du kannst den Wortlaut vor dem Speichern bearbeiten.

TipDie drei Deployment succeeded-Automatisierungen reagieren nur auf Produktions-Deployments, sodass Vorschau-Deployments (zum Beispiel von Vercel) keine Statusseiten-Posts oder Cache-Leerungen auslösen.

#Beispiele

• SSL-Erneuerung fehlgeschlagen → ein GitHub-Issue erstellen, mit dem Label infrastructure versehen und deinem DevOps-Team zuweisen.
• Ein Vorfall wurde behoben → das verknüpfte Issue kommentieren und dann schließen, wobei Linked records die Issue-Nummer und das Repository liefert. Wurde kein Issue geöffnet, wird der Schritt übersprungen.
• Ein Pull Request wurde in main gemergt → deinen Deploy-Workflow ausführen und dann den Deployment-Status setzen.
• Dein Produktions-Health-Check war erfolgreich → den Commit-Status auf „Erfolg“ setzen.
• Ein Release wurde veröffentlicht → eine Statusseiten-Ankündigung posten.

#Gut zu wissen

• Ein GitHub-Trigger löst erst aus, wenn GitHub verbunden ist und die App diesen Ereignistyp abonniert hat. Läuft ein Trigger nie, bitte deine Administratorin oder deinen Administrator, die Ereignisabonnements der App zu prüfen.
• Aktionen, die deine eigenen Automatisierungen auf GitHub ausführen – ein Kommentar, ein Label, ein gestarteter Workflow – lösen deine GitHub-Trigger nicht erneut aus, sodass eine Regel nicht endlos auf ihren eigenen Kommentar reagieren kann.
• Verbinden zwei deiner InfraNest-Workspaces dasselbe GitHub-Konto, reagieren Automatisierungen in beiden auf dessen Ereignisse.
• Erstellt ein Schritt etwas (wie ein Issue oder Deployment), können spätere Schritte in derselben Regel es automatisch wiederverwenden.
• Ein Review von einem Team anzufordern erfordert eine Organisations-Verbindung, keine persönliche.
• Manche Aktionen benötigen möglicherweise einen höheren Plan – diese zeigen im Editor ein Pro-Abzeichen.
• Pull Request mergen mergt nur genau den Commit, den die Regel gesehen hat; pusht jemand danach etwas, wird nichts gemergt, und der Lauf erklärt den Grund.
• Lasse den Workflow-Branch leer, um den Standard-Branch des Repositorys zu verwenden.
• Retry on transient failure deckt GitHub-Ausfälle, Timeouts und Rate-Limits ab; eine echte Ablehnung zeigt im Laufverlauf den Grund von GitHub selbst.
• Zeigt ein Schritt auf ein Issue, das früher in der Regel erstellt werden sollte, aber keines erstellt wurde, wird der Schritt übersprungen, nicht als fehlgeschlagen markiert.