InfraNestInfraNest
GitHub

Automatiseren met GitHub

Bouw regels die reageren op GitHub-activiteit en actie ondernemen op GitHub — geen scripts, geen koppelcode.

Werkt op Free · sommige opties vragen ProBijgewerkt 2 november 20266 min lezen

Automatiseren met GitHub laat je regels bouwen die reageren op activiteit in je repositories en actie ondernemen op GitHub — geen scripts nodig. Het is voor iedereen die wil dat incidenten, deployments en infrastructuurgebeurtenissen synchroon blijven lopen met hun GitHub-workflow.

#Overzicht

  • Start automatiseringen vanuit GitHub-gebeurtenissen zoals workflow-runs, issues, pull requests, pushes, releases en deployments.
  • Laat InfraNest actie ondernemen op GitHub: issues openen, pull requests mergen, workflows starten, commitstatussen instellen en meer.
  • Gebruik kant-en-klare automatiseringen om GitHub in een paar klikken te koppelen aan incidenten, certificaten, domeinen en je statuspagina.

NoteGitHub-triggers vereisen dat de InfraNest Automations-app geïnstalleerd is. Een koppeling die alleen met een token is gemaakt, kan alleen GitHub-acties uitvoeren — die kan geen regel starten vanuit GitHub-activiteit.

#Koppel GitHub voordat je begint

  1. Ga naar Integraties en koppel je GitHub-account (zie Connect GitHub).
  2. In de automatiseringsbouwer verschijnen GitHub-triggers en -acties samen onder de groep GitHub.
  3. Als je een GitHub-trigger kiest voordat je hebt gekoppeld, 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 een workflow-run, een issue, een pull request, een push, een release, een deployment, of een voltooide check.
  2. Voeg Alleen als-filters toe om dingen te verfijnen, zoals een specifieke branch, repository, of alleen mislukkingen. Repository- en accountvelden stellen je gekoppelde repo's voor terwijl je typt.
  3. Filter bij pushes op Branch of tag en Verwijderd als je alleen nieuwe commits op een branch wilt, niet verwijderde branches of tags.
  4. Filter bij reacties op Op een pull request als je alleen reacties op pull requests wilt, aangezien reacties op issues en PR's op dezelfde manier binnenkomen.
  5. Voeg bij releases “Actie is gelijk aan published” toe zodat de regel één keer per release draait in plaats van drie keer. De bouwer kan dit filter voor je toevoegen.
  6. Stel indien nodig een afkoeltijd in — die geldt per issue, workflow, commit of deployment, en houdt nooit een andere repository tegen.
Automatiseren met GitHub

#Actie ondernemen op GitHub (acties)

  1. Selecteer onder Doe dit Actie toevoegen en kies een GitHub-actie — bijvoorbeeld GitHub-workflow starten, GitHub-issue aanmaken, Pull request mergen, GitHub-deployment aanmaken, GitHub-release aanmaken, of Commitstatus instellen.
  2. Kies welke GitHub-koppeling de actie moet gebruiken. Als je er maar één hebt, is die al geselecteerd.
  3. Vul velden in zoals repository, workflow, branch, omgeving, labels of toegewezen personen — deze bieden een doorzoekbare lijst op basis van je gekoppelde GitHub, of je kunt een waarde typen of een placeholder uit de trigger invoegen.
  4. Als een veld zijn lijst niet kan laden, controleer dan het bericht eronder — dat vertelt je of je opnieuw moet koppelen in Integraties, de app op GitHub moet deactiveren opheffen, een rechten moet verlenen, of de app toegang moet geven tot die repository.
Automatiseren met GitHub

#Maak van incidenten en waarschuwingen GitHub-issues

  1. Om automatisch een issue te openen voor elk incident, ga naar Integraties → GitHub, open Connections & settings, zet Issues for Incidents aan, en kies de Repository. Het oplossen van het incident sluit het issue; een herhaald incident terwijl het issue nog open staat, voegt een reactie toe in plaats van een nieuw issue aan te maken.
  2. Om handmatig van één incident of waarschuwing een issue te maken, open je het ⋯-menu (of Create issue onder Follow-up op de pagina van een incident), selecteer Create a GitHub issue, kies de repository, controleer What we send, en maak het aan. De kaart toont dan het issue, zoals infra#42 · Open.
  3. Als er al een issue bestaat, selecteer Link an existing issue en plak het adres of owner/repo#42.
  4. Als het dialoogvenster al een bijpassend open issue vindt in de gekozen repository, biedt het Link that one instead aan.
  5. Als het issue gesloten is maar het probleem niet opgelost, gebruik dan Reopen infra#42 uit hetzelfde menu.

NoteRepositories met issues uitgeschakeld, en gearchiveerde repositories, worden niet aangeboden, omdat GitHub het issue zou weigeren.

#Begin met een kant-en-klare automatisering

  1. Open GitHub onder Integraties en kijk onder Ready-made automations, of ga naar Automatiseringen → Templates.
  2. Selecteer Use bij de sjabloon die je wilt.
  3. Kies de repository of statuspagina die hij moet gebruiken.
  4. Selecteer Automatisering opslaan.
Automatiseren met GitHub

Handige kant-en-klare automatiseringen zijn onder meer:

  • Incident opened → open a GitHub issue, gecombineerd met Incident resolved → close its GitHub issue, zodat issues zichzelf automatisch bijhouden en sluiten.
  • Certificate expiring → open a GitHub issue, verstuurd twee weken voor het verlopen.
  • Domain expiring → open a GitHub issue, verstuurd een maand voor het verlopen.
  • Release published → announce on status page, alleen voor volledige releases (niet voor pre-releases).
  • GitHub workflow failed → re-run failed jobs once, zodat een wisselvallige job een tweede kans krijgt zonder eindeloze pogingen.
  • Deployment succeeded → check it is up → set commit status, die de omgeving controleert zodra GitHub de deployment meldt en de commit groen of rood markeert op basis van wat gevonden is.
  • Deployment succeeded → purge the Cloudflare cache Pro, zodat bezoekers direct de nieuwe build zien.
  • Deployment succeeded → announce on status page.
  • GitHub workflow failed → open an issue & alert.
  • Certificate expiring → run a GitHub workflow.

Titels en berichten in deze sjablonen zijn vooraf geschreven met placeholders (zoals Released: {{tag}}) die automatisch worden ingevuld wanneer de automatisering draait. Je kunt de tekst aanpassen voordat je opslaat.

TipDe drie Deployment succeeded-automatiseringen reageren alleen op productiedeploys, zodat previewdeployments (bijvoorbeeld van Vercel) geen statuspagina-berichten of cache-leegmakingen activeren.

#Voorbeelden

  • SSL-vernieuwing mislukt → maak een GitHub-issue aan, voorzie het van het label infrastructure, en wijs het toe aan je DevOps-team.
  • Een incident opgelost → reageer op het gekoppelde issue, sluit het daarna, met behulp van Gekoppelde items voor het issuenummer en de repository. Als er geen issue was geopend, wordt de stap overgeslagen.
  • Een pull request gemerged in main → draai je deploy-workflow, stel daarna de deploymentstatus in.
  • Je productie-health-check is geslaagd → stel de commitstatus in op geslaagd.
  • Een release is gepubliceerd → plaats een statuspagina-aankondiging.

#Goed om te weten

  • Een GitHub-trigger gaat pas af 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.
  • Acties die je eigen automatiseringen op GitHub uitvoeren — een reactie, een label, een gestarte workflow — activeren je GitHub-triggers niet opnieuw, zodat een regel niet eindeloos op zijn eigen reactie kan reageren.
  • Als twee van je InfraNest-workspaces 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 hergebruiken.
  • Een review aanvragen bij een team vereist een organisatiekoppeling, geen persoonlijke koppeling.
  • Sommige acties vereisen mogelijk een hoger abonnement — deze tonen een Pro-badge in de bouwer.
  • Pull request mergen merget alleen de exacte commit die de regel heeft gezien; als iemand daarna pusht, wordt er niets gemerged, en de run legt uit waarom.
  • Laat de workflow-branch leeg om de standaardbranch van de repository te gebruiken.
  • Opnieuw proberen bij tijdelijke fout dekt GitHub-storingen, time-outs en rate limits; een echte weigering toont GitHub's eigen reden in de runhistorie.
  • Als een stap verwijst naar een issue dat eerder in de regel aangemaakt had moeten worden en er is geen issue aangemaakt, wordt de stap overgeslagen, niet als mislukt gemarkeerd.

Gerelateerde artikelen

Begin in seconden

Breng je hele infrastructuur samen in één modern dashboard.

Gratis plan · Geen creditcard nodig · In enkele minuten ingesteld