Automatiseer met GitHub

Met Automatiseer met GitHub bouw je regels die reageren op activiteit in je GitHub-repositories en actie ondernemen op GitHub — zonder scripts. Dit is voor iedereen die infrastructuur- of incidentworkflows beheert naast een GitHub-gebaseerd ontwikkelteam.

Overzicht

• Start automatiseringen vanuit GitHub-gebeurtenissen zoals workflow-runs, issues, pull requests, pushes, releases en deployments
• Voer automatisch acties uit op GitHub — maak issues aan, merge pull requests, start workflows, stel commitstatus in, en meer
• Combineer GitHub met de rest van InfraNest, zoals het openen van een GitHub-issue wanneer een incident start

Voordat je begint

1. Ga naar Integraties en koppel je GitHub-account.
2. Om GitHub-triggers te gebruiken (de Wanneer dit gebeurt-kant van een regel) heb je de GitHub App InfraNest Automations nodig — een tokenkoppeling kan alleen GitHub-acties uitvoeren, niet triggeren vanuit GitHub-gebeurtenissen.
3. In de automatiseringsbouwer verschijnen GitHub-triggers en -acties samen onder de groep GitHub.
4. Als je een GitHub-trigger kiest voordat je gekoppeld hebt, herinnert InfraNest je eraan om eerst te koppelen.

Reageren op GitHub-activiteit (triggers)

1. Start een nieuwe automatisering en kies onder Wanneer dit gebeurt een GitHub-trigger — bijvoorbeeld GitHub-workflow-run, GitHub-issue, GitHub-pull request, GitHub-push, GitHub-release, GitHub-deployment, GitHub-deploymentstatus, GitHub-commitstatus of GitHub check run.
2. Voeg Alleen als-filters toe om dingen te beperken — bijvoorbeeld alleen de Branch, alleen een specifieke Repository, alleen mislukkingen, of alleen je Organisatie. De velden Repository en account suggereren je gekoppelde repo's en accounts terwijl je typt.
3. Houd rekening met een aantal filtereigenaardigheden:
   • GitHub-push-gebeurtenissen omvatten ook tags en verwijderde branches — filter op Branch en Deleted om alleen op nieuwe commits te reageren.
   • GitHub-reactie (issue of PR) wordt getriggerd voor zowel issues als pull requests — filter op Op een pull request om er één te kiezen.
   • GitHub-release wordt drie keer per release getriggerd. Voeg “Actie is gelijk aan published” toe zodat je regel één keer draait — de bouwer biedt aan dit voor je toe te voegen.
   • Toegewezen aan (iedereen) komt overeen bij elke issue-gebeurtenis; Toegewezen persoon komt alleen overeen met de persoon die net is toegewezen of verwijderd.
   • Productieomgeving onderscheidt een productiedeploy van een previewdeploy.
   • Poging telt workflow-herstarts — 1 is de eerste run.
   • Afkoeltijd geldt per issue, workflow, commit of deployment — een afkoeltijd op één repository blokkeert nooit een andere.

Actie ondernemen op GitHub (acties)

1. Selecteer onder Doe dit de optie Actie toevoegen en kies een GitHub-actie, zoals GitHub-workflow starten, GitHub-workflow opnieuw uitvoeren, Mislukte jobs opnieuw uitvoeren, GitHub-run annuleren, GitHub-issue aanmaken, Reageren op GitHub-issue, GitHub-issue bijwerken, GitHub-issue sluiten, GitHub-issue heropenen, Labels toevoegen, Label verwijderen, GitHub-issue toewijzen, Pull request mergen, PR-review aanvragen, GitHub-deployment aanmaken, Deploymentstatus instellen, GitHub-release aanmaken, of Commitstatus instellen.
2. Kies welke GitHub-koppeling de actie moet gebruiken. Als je er maar één hebt, wordt deze automatisch gekozen.
3. Vul velden in zoals Repository (owner/repo), Workflow-bestand of id, Branch, Omgeving, Labels (komma-gescheiden), Toegewezen personen (komma-gescheiden) en Reviewers — deze bieden een doorzoekbare lijst van je gekoppelde GitHub, of je kunt zelf een waarde typen of een placeholder uit de trigger invoegen.
4. Als een lijst niet wil laden, controleer het bericht onder het veld:
   • De koppeling moet opnieuw gekoppeld worden — koppel deze opnieuw in Integraties.
   • De GitHub App is opgeschort — hef de opschorting op GitHub op onder Settings → GitHub Apps → Configure.
   • Het mag die lijst niet lezen — geef de toestemming op GitHub.
   • Het kan die repository niet zien — voeg de repository toe aan de toegang van de app op GitHub, of gebruik een token dat er wel bij kan.
   • GitHub was zojuist niet bereikbaar — probeer het straks opnieuw.

Starten met een kant-en-klare automatisering

1. Open GitHub onder Integraties en zoek naar Ready-made automations, of ga naar Automatiseringen en open Sjabloonbibliotheek.
2. Selecteer Gebruiken bij een sjabloon, kies de repository of statuspagina waarmee deze moet werken, en selecteer Automatisering opslaan.

Nuttige kant-en-klare automatiseringen die GitHub verbinden met de rest van je opzet:

• Incident geopend → open een GitHub-issue, gecombineerd met Incident opgelost → sluit het GitHub-issue, zodat issues zichzelf automatisch volgen en sluiten.
• Certificaat verloopt → open een GitHub-issue, twee weken vooraf.
• Domein verloopt → open een GitHub-issue, een maand vooraf.
• Release gepubliceerd → aankondigen op statuspagina, alleen voor volledige releases (pre-releases worden overgeslagen).
• GitHub-workflow mislukt → mislukte jobs één keer opnieuw uitvoeren — een onstabiele job krijgt één nieuwe poging, daarna wordt het aan jou overgelaten.
• Deployment geslaagd → controleren of deze actief is → commitstatus instellen — InfraNest controleert je omgeving direct nadat GitHub de deployment meldt en markeert de commit dienovereenkomstig. Deze controle heeft geen invloed op monitor-uptime of openstaande incidenten.
• Deployment geslaagd → Cloudflare-cache legen.
• Deployment geslaagd → aankondigen op statuspagina.
• GitHub-workflow mislukt → issue openen & waarschuwen, en Certificaat verloopt → GitHub-workflow uitvoeren.

NoteDe drie Deployment geslaagd-automatiseringen reageren alleen op productiedeployments, zodat previewdeployments geen aankondigingen of cache-leegacties triggeren.

Voorbeelden

1. SSL-verlenging mislukt → GitHub-issue aanmaken, voeg het label infrastructure toe en stel Toegewezen personen (komma-gescheiden) in op je DevOps-team.
2. Incident opgelost → Reageren op GitHub-issue, gevolgd door GitHub-issue sluiten — met behulp van Gekoppelde items om het issuenummer en de repository automatisch in te vullen. Als er voor dat incident geen issue is geopend, wordt de stap overgeslagen.
3. GitHub-pull request gemerged naar een branch → GitHub-workflow uitvoeren, gevolgd door Deploymentstatus instellen.
4. Een productie-gezondheidscheck slaagt → Commitstatus instellen op geslaagd.
5. GitHub-release gepubliceerd → Statuspagina-aankondiging plaatsen.

Goed om te weten

• Een GitHub-trigger wordt alleen geactiveerd zodra GitHub gekoppeld is en de app geabonneerd is op dat type gebeurtenis. Als een trigger nooit draait, vraag je beheerder om de event-abonnementen van de app te controleren.
• Automatiseringen die je uitvoert, triggeren je eigen GitHub-triggers niet opnieuw — dit voorkomt dat een regel eindeloos op zijn eigen reacties of labels reageert.
• Als twee InfraNest-werkruimtes hetzelfde GitHub-account koppelen, reageren automatiseringen in beide op de gebeurtenissen ervan.
• Wanneer één stap iets aanmaakt (zoals een issue of deployment), kunnen latere stappen in dezelfde regel dit automatisch opnieuw gebruiken.
• Een review aanvragen bij een team vereist een organisatiekoppeling, geen persoonlijke koppeling.
• Sommige acties tonen een Pro-badge en vereisen een hoger abonnement.

TipLaat het workflow-branchveld leeg om de standaardbranch van de repository te gebruiken — deze hoeft niet main te heten.

Problemen oplossen

• Pull request mergen merget alleen wat de regel heeft gezien. Als iemand nieuwe commits pusht na de goedkeuring die de regel startte, wordt er niets gemerged, en de run legt uit waarom.
• Opnieuw proberen: stel Opnieuw proberen bij tijdelijke fout in om automatisch opnieuw te proberen bij een GitHub-storing, time-out of rate limit. Een permanente weigering toont de eigen reden van GitHub in Runhistorie.
• Als een latere stap verwijst naar een issue dat eerder zou zijn aangemaakt (via Gekoppelde items) en er geen is aangemaakt, wordt die stap overgeslagen in plaats van als mislukt gemarkeerd.