Kan AI finde fejlen i din CI/CD-pipeline?

Tag et forenklet eksempel: En integrationstest fejler i CI, selv om den kører uden problemer lokalt, og den seneste kodeændring ikke ser ud til at berøre databasen. Loggen ender med fejlen: connection to server at "localhost", port 5432 failed: Connection refused.

Det er fristende at kopiere fejlmeddelelsen ind i en AI-assistent og spørge: “Hvordan løser jeg det?”

Modellen vil sandsynligvis foreslå, at PostgreSQL ikke kører, at porten er forkert, eller at forbindelsesstrengen mangler. Alle tre forklaringer er plausible. Men en plausibel forklaring er ikke i sig selv en diagnose.

AI er mest nyttig i pipeline-fejlsøgning, når den bruges til at opstille hypoteser og finde forskelle – ikke når den bliver bedt om at gætte en rettelse ud fra de sidste linjer i loggen.

Den synlige fejl kan ligge et andet sted end årsagen

I dette eksempel kører integrationstesten i GitHub Actions med PostgreSQL som servicecontainer. Databasen er defineret, port 5432 er eksponeret til runneren, og applikationen bruger den forventede forbindelsesstreng.

Men pipelinen kontrollerer ikke, om PostgreSQL er klar til at modtage forbindelser, før testene starter. Servicecontaineren kan derfor være oprettet, mens databasen stadig initialiseres.

Fejlen bliver synlig i applikationens databaseforbindelse. Årsagen ligger i rækkefølgen og timingen mellem to dele af pipelinen.

Det er den slags sammenhæng, AI kan hjælpe med at finde. Men kun hvis modellen får mere end den sidste fejlmeddelelse.

Giv AI konteksten omkring fejlen

En stack trace fortæller modellen, hvad der fejlede. Den fortæller ikke, hvorfor fejlen kun opstår i CI.

Et bedre input samler fire typer information:

• fejlen og det første tidspunkt, hvor buildet afviger
• den relevante del af pipelinekonfigurationen
• forskellen mellem det fungerende og det fejlende miljø
• ændringer i kode, dependencies og images siden seneste fungerende build

Bed derefter AI opstille eksempelvis tre sandsynlige hypoteser. For hver hypotese skal den beskrive, hvilke observationer der understøtter forklaringen, hvad der taler imod den, og hvilken kontrol der kan be- eller afkræfte den.

Bed den vente med at foreslå en rettelse. Det gør svaret lettere at kontrollere, fordi modellen først skal vise, hvordan dens forklaringer kan testes.

En sandsynlig forklaring i vores eksempel er derfor, at testene starter, før databasen er klar til at modtage forbindelser. Det skal dog bekræftes i pipelinen, før konfigurationen ændres.

Sammenlign et fejlet og et fungerende build

Et af de mest nyttige input er ofte ikke mere fra den fejlede log, men den tilsvarende del af et build, der bestod.

Bed AI sammenligne de to forløb kronologisk og ignorere ubetydelige forskelle som job-id’er, tilfældige filnavne og absolutte tidsstempler. Opgaven er at finde den første meningsfulde forskel – ikke blot den sidste fejl.

Sammenligningen kan eksempelvis vise, at PostgreSQL meldte sig klar, før testene begyndte i det fungerende build. I det fejlede build forsøgte testene derimod at oprette forbindelse, mens databasen stadig blev initialiseret.

Det indsnævrer søgerummet. Modellen skal ikke længere gætte på hele teknologistakken, men forklare forskellen mellem to næsten ens forløb.

Metoden kan også bruges, når en test kun fejler på én runner, efter en opdatering af et base image eller ved en bestemt kombination af dependency-versioner.

Kontrollér, om databasen er klar – men stop ikke dér

Hypotesen kan afprøves ved at kontrollere PostgreSQL umiddelbart før integrationstesten. Hvis readiness-kontrollen fejler i de samme builds som testen, peger det på databasens tilstand frem for applikationens forbindelseslogik.

GitHub viser selv en health check med pg_isready i sin vejledning til PostgreSQL-servicecontainere. En sådan kontrol kan eksempelvis køres hvert femte sekund og afbrydes efter et fast antal mislykkede forsøg.

Men her gemmer sig en vigtig begrænsning: pg_isready kontrollerer, om PostgreSQL svarer og accepterer forbindelser. Kommandoen kan melde, at serveren er klar, selv om det angivne brugernavn eller databasenavn er forkert. Det fremgår af PostgreSQLs dokumentation for pg_isready.

En grøn health check dokumenterer derfor ikke, at applikationen er klar. Den viser kun, at databasetjenesten svarer.

Hvis integrationstesten kræver bestemte tabeller, migrationer eller extensions, bør pipelinen også udføre en applikationsnær kontrol. Den kan eksempelvis undersøge, om den forventede migration er registreret, om nødvendige tabeller findes, og om en simpel forespørgsel kan gennemføres.

Det skelner mellem tre tilstande:

1. Containeren er startet.
2. PostgreSQL accepterer forbindelser.
3. Databasen er klar til netop denne applikation.

Det er ofte overgangen mellem trin 2 og 3, en generisk health check overser.

Først når den relevante tilstand kan observeres, giver det mening at ændre pipelinekonfigurationen. Ved sporadiske fejl bør rettelsen derefter afprøves gentagne gange under de samme betingelser. Ét grønt build viser kun, at fejlen ikke opstod denne gang.

Pipeline-logs er ikke nødvendigvis uskadelige data

Logs kan indeholde interne adresser, repository-oplysninger, payloads, persondata og credentials. GitHub maskerer registrerede secrets i workflow-logs, men understreger samtidig, at maskeringen ikke er garanteret i alle tilfælde. Det skyldes blandt andet, at værdier kan være transformeret, inden de skrives til loggen.

Før logdata sendes til en ekstern AI-tjeneste, bør udtrækket derfor afgrænses og renses for forbindelsesstrenge, tokens, interne identifikatorer og produktionsdata.

Der er også en mindre åbenlys risiko: Logoutput kan indeholde tekst, som andre kontrollerer, eksempelvis branch-navne, commitbeskeder, testdata eller svar fra eksterne systemer.

AI-modeller skelner ikke nødvendigvis sikkert mellem instruktioner og data. OWASP anbefaler derfor i sin vejledning om prompt injection, at eksternt indhold behandles som utroværdigt input, og at modeloutput valideres, før det bruges i efterfølgende handlinger.

Loggen bør præsenteres eksplicit som data. Modellens forslag bør heller ikke sendes direkte videre til en shell eller pipeline.

AI kan indsnævre fejlen – men pipelinen skal bevise den

AI kan forkorte vejen fra en uoverskuelig log til en håndfuld kvalificerede forklaringer. Den kan sammenligne builds, gruppere følgefejl og pege på manglende kontroller.

Men modellen kan ikke afgøre, om to hændelser har en årsagssammenhæng, alene fordi de optræder tæt på hinanden.

Det mest nyttige spørgsmål er derfor: Hvilke forklaringer passer til det, vi kan observere – og hvilken kontrol kan afgøre, om de holder?

Så bliver AI en del af fejlsøgningen, mens det stadig er pipelinen og de reproducerbare resultater, der afgør konklusionen.