>_ DevTrendsnl

Taal

Home

Talen

Secties

Frontend Backend Mobiel DevOps AI / ML GameDev Blockchain Beveiliging
Go

Hoe je GitHub Actions rapporten laat schrijven en code analyseert met gewone tekst

4.706 sterren

Stel je voor dat je 's ochtends op je werk arriveert, GitHub opent, en er al een nette Issue op je wacht met een samenvatting van alle discussies van gisteren, een lijst met kritieke bugs, en zelfs een conceptplan voor de dag. En dit alles is niet gedaan door je stagair, maar door een geautomatiseerde agent aan wie je simpelweg een notitie in Markdown hebt geschreven.

Klinkt als een toekomstscenario? Eigenlijk is dit al realiteit die GitHub actief test als onderdeel van het gh-aw-project (Agentic Workflows). Laten we uitzoeken waarom dit de manier waarop we CI/CD-pipelines schrijven voorgoed zou kunnen veranderen.

Wat zijn Agentic Workflows en waarom hebben we ze nodig

Meestal omvat het instellen van GitHub Actions het schrijven van YAML-configs waarin je het systeem stap voor stap instrueert: "download de repository", "installeer dependencies", "voer het script uit". Dit werkt prima voor voorspelbare taken, maar schiet tekort wanneer je te maken hebt met iets creatiefs of analytisch.

Het gh-aw-project biedt een andere aanpak. In plaats van een rigide algoritme te schrijven, beschrijf je de taak in natuurlijke taal. Een speciale CLI-extensie converteert je Markdown-bestand naar een volledige Workflow, waarbij een AI-agent (bijvoorbeeld Copilot of Claude) op de achtergrond werkt. Deze beslist zelf welke data uit de repository hij moet lezen, hoe hij deze moet analyseren, en welk resultaat hij moet produceren.

Dit is de ideale tool voor wie "menselijke" routines wil automatiseren: rapporten schrijven, documentatie controleren op actualiteit, of initiële ticket-sortering.

Hoe het in de praktijk werkt

Het mooiste hier is de lage instapdrempel. Je hoeft geen expert te zijn in Prompt Engineering of de GitHub API diepgaand te kennen.

Hier is een voorbeeld van hoe een taakbeschrijving eruitziet:

---
on:
  schedule: daily
permissions:
  contents: read
  issues: read
  pull-requests: read
safe-outputs:
  create-issue:
    title-prefix: "[team-status] "
    labels: [report, daily-status]
    close-older-issues: true
---

## Daily Issues Report

Создай бодрый ежедневный отчет для команды в виде GitHub issue. 
Проанализируй открытые задачи и выдели самые важные.

Wanneer deze workflow draait, betreedt de agent je repository, "leest" de laatste events, en maakt een Issue. Merk op dat we in blok safe-outputs de permissies van de agent duidelijk beperken: hij kan tickets aanmaken, maar alleen met een specifiek prefix en tags. Dit is geen "black box" met volledige toegang, maar een gecontroleerde assistent.

Drie pijlers van veiligheid: waarom de agent je prod niet zal verwijderen

Wanneer we een neuraal netwerk toegang geven tot code, is de eerste vraag die opkomt "Zal het geen problemen veroorzaken?". De ontwikkelaars van GitHub Next hebben hier enorm veel aandacht aan besteed:

  1. Principe van Minimale Rechten: Standaard heeft de agent alleen leesrechten. Om iets te kunnen schrijven (een PR of Issue aanmaken), moet je dit expliciet toestaan in de config.
  2. Sandboxing: Alle acties worden uitgevoerd in geïsoleerde containers. De agent kan niet zomaar "ontsnappen" naar je infrastructuur.
  3. Netwerk Firewall (AWF): In het ecosysteem van het project zit een speciaal onderdeel — Agent Workflow Firewall. Deze controleert waar de agent probeert data naartoe te sturen, waardoor lekken worden voorkomen.

Wat het gh-aw-ecosysteem nog meer kan

Het project beperkt zich niet alleen tot de CLI. Het is een complete infrastructuur voor het creëren van slimme assistenten:

  • MCP Gateway: Maakt het mogelijk om externe tools te verbinden via het Model Context Protocol. Dit betekent dat je agent niet alleen GitHub kan lezen, maar ook in andere services kan kijken als je hem die mogelijkheid geeft.
  • The Agentics: Een verzameling kant-en-klare componenten en templates. Geen wiel opnieuw uitvinden — je kunt kant-en-klare "bouwstenen" nemen voor typische taken.
  • Compile-time validatie: Het systeem controleert je Markdown-bestand voordat het draait om te verzekeren dat de agent de instructies begrijpt en de noodzakelijke permissies heeft.

Wie heeft hier vandaag al profijt van

In mijn praktijk kom ik vaak taken tegen die "te complex zijn voor Bash, maar te saai voor een mens".

Bijvoorbeeld:

  • Documentatie-onderhoud: Een agent kan wekelijks controleren of functiesignaturen in de code zijn veranderd, en als de README verouderd is — wijzigingen voorstellen.
  • Sentimentanalyse: In grote Open Source-projecten kan een agent comments monitoren en voor maintainers die discussies uitlichten waar het niveau van toxiciteit of ontevredenheid toeneemt.
  • Changelog-generatie: In plaats van pijnlijk te proberen te onthouden wat je de afgelopen maand hebt geprogrammeerd, kun je de agent vragen om een mooie lijst van wijzigingen samen te stellen op basis van merge requests.

Conclusie: Is het de moeite waard om te proberen?

GitHub Agentic Workflows is nog experimenteel terrein (zoals de banner WARNING in de repository eerlijk waarschuwt). Echter, dit is naar alle waarschijnlijkheid de meest volwassen aanpak voor het integreren van AI in CI/CD op dit moment.

Als je genoeg hebt van routinematig rapporteren of wat extra "hersenen" aan je repository wilt toevoegen, is het zeker de moeite waard om gh aw te installeren en te proberen om ten minste één simpel rapport te draaien. Het is een geweldige manier om te voelen hoe AI verandert van een speeltje in een echt werkend ontwikkelaarstool.

Klaar om een deel van je werk te delegeren aan een bot? Bekijk Peli's Agent Factory — daar vind je veel inspirerende voorbeelden van wat deze agents nu al kunnen doen.

Gerelateerde projecten