Technische Samenvatting: Taming the Drift: Context-bewuste reparatie van Dockerfile-drift tijdens software-evolutie

1. Probleemdefinitie: Dockerfile-drift

Moderne softwareontwikkeling leunt zwaar op Continuous Integration en Continuous Deployment (CI/CD) pipelines, waarbij Docker de de facto standaard is voor het waarborgen van reproduceerbare build-omgevingen. Echter, een kritiek probleem dat bekend staat als Dockerfile-drift ondermijnt deze betrouwbaarheid. Drift treedt op wanneer een Dockerfile er niet in slaagt de wijzigingen in de broncode van de applicatie te absorberen, wat leidt tot een mismatch tussen het build-script en de evoluerende status van de repository. In tegenstelling tot syntactische fouten is drift een intern co-evolutieprobleem waarbij de informatie voor de reparatie zich binnen dezelfde repository bevindt die de fout heeft geproduceerd.

Drift manifesteert zich als incorrecte bestiepaden, mismatches in omgevingsvariabelen, verouderde afhankelijkheidsspecificaties of veranderingen in platformen. Deze fouten zijn bijzonder moeilijk automatisch te repareren vanwege drie kernuitdagingen:

• C1 (Contextextractie): De build-status (werkmap, omgevingsvariabelen, bestandssets) wordt bepand door de cumulatieve uitvoering van eerdere instructies, niet alleen door de tekst van de Dockerfile. Bestaande regelgebaseerde en LLM-gebaseerde methoden behandelen de Dockerfile vaak in isolatie, waardoor ze de dynamische interacties niet modelleren.
• C2 (Instructieoverstijgende afhankelijkheden): Instructies hangen vaak af van artefacten die door eerdere stappen zijn geproduceerd op niet-voor de hand liggende manieren (bijv. een RUN-commando dat opereert op bestanden die door een voorafgaande COPY of ARG zijn geïntroduceerd). Deze afhankelijkheden zijn syntactisch niet zichtbaar in isolatie.
• C3 (Locatie van de grondoorzaken): Foutlogs wijzen vaak naar de falende instructie, maar identificeren zelden de grondoorzaak, die kan voortkomen uit een wijziging in de code die in een eerdere commit is geïntroduceerd.

2. Methodologie: Het Cadre-framework

De auteurs stellen Cadre voor, een contextbewust framework ontworpen om Dockerfile-drift te repareren door de build-context expliciet te modelleren. Het centrale ontwerpinzicht is dat de contextstructuur de kwaliteit van de reparatie bepaalt, meer dan de contextvolume. Cadre pakt de drie uitdagingen aan via vier geïntegreerde fasen:

2.1 Dockerfile Drift Extractor (DodeX)

Om het gebrek aan realistische benchmarks aan te pakken, hebben de auteurs DodeX ontwikkeld, een pipeline die real-world drift-instanties uit GitHub Actions CI-logs minent. In tegenstelling tot statische snapshot-datasets legt DodeX de volledige build-configuratie vast, inclus\u00admet dynamische build-argumenten, doelplatformen en de exacte code-wijzigingsdiffs die de fout hebben getriggerd. Dit zorgt ervoor dat elke geëxtraheerde instantie lokaal reproduceerbaar is.

2.2 Instruction-level Context Profiler

Om C1 op te lossen, voert Cadre een stateful simulatie uit van het Docker build-proces. Het doorloopt de Dockerfile instructie voor instructie en houdt een Context State ($\sigma$) bij die het volgende bijhoudt:

• De huidige werkmap ($\delta$).
• Geresolveerde omgevingsvariabelen ($\varepsilon$).
• De set bestanden die aanwezig zijn in de container ($\Phi$).

Cruciaal is dat de profiler gebruikmaakt van build-systeem-bewuste parsers voor 11 belangrijke ecosystemen (bijv. Go, Python, npm, Maven). In plaats van RUN-commando's als opaak tekst te behandelen, leiden deze parsers impliciete bestandafhankelijkheden af (bijv. het afleiden dat go build afhankelijk is van go.mod en alle *.go bestanden in de directory). Dit produceert een Instruction Context Map (ICM) die elke instructie koppelt aan de precieze build-time status.

2.3 Context-aware Dependency Graph (CDG)

Om C2 op te lossen, wordt de ICM omgezet in een Context-aware Dependency Graph (CDG), een gerichte acyclische graaf ($G = (V, E)$) die de afhankelijkheden tussen instructies expliciet maakt:

• Vertices (Knopen): Omvatten instructieknopen ($V_I$) en bestandsknopen ($V_F$).
• Edges (Randen): Omvatten sequentiële randen ($E_S$) die de control flow vertegenwoordigen en dataflow-randen ($E_D$) die "read-from" afhankelijkheden vertegenwoordigen tussen bestanden en instructies.
  Deze graaf stelt het systeem in staat om foutpropagatiepaden over instructiegrenzen heen te traceren, waardoor wordt geïdentificeerd hoe een wijziging in een bronbestand (bijv. go.mod) een specifieke RUN-instructie ongeldig maakt via tussenliggende COPY of ARG stappen.

2.4 Context-refined Repair Workflow

Om C3 op te lossen en de tokenlimieten te beheren, gebruikt Cadre een tweestaps agentic workflow in plaats van een single-shot prompt:

1. Context Inquiry (Context-opvraag): De LLM krijgt de foutlog, de code-diff en een geprunede versie van de CDG gepresenteerd. Er wordt gevraagd om de minimale set relevante bestanden en grep-keywords te selecteren die nodig zijn voor de reparatie. Deze stap filtert irrelevante context uit voordat de inhoud van de bestanden wordt geladen.
2. Repair Generation (Reparatiegeneratie): Het systeem haalt alleen de geselecteerde bestanden op en genereert een gerichte patch.
   Deze aanpak voorkomt prompt-overflow (een veelvoorkomende foutmodus bij concurrerende LLM-methoden) en zorgt ervoor dat het model zich concentreert op causaal relevante bewijslast.

3. Belangrijkste Bijdragen

• Cadre Framework: Een nieuw reparatieframework dat geworteld is in het inzicht dat contextstructuur waardevoller is dan contextvolume. Het integreert een stateful context profiler, een dependency graph en een tweestaps LLM-workflow.
• DodeX en $D^3$ Benchmark: De creatie van DodeX, een pipeline voor het extraheren van drift-instanties met volledige build-configuraties, en $D^3$, de eerste Dockerfile-drift benchmark waar alle 1.040 instanties lokaal reproduceerbaar zijn met exacte parameters uit de originele CI-runs.
• Empirische Evaluatie: Een uitgebreide evaluatie die Cadre vergelijkt met regelgebaseerde baselines (Parfum), retrieval-gebaseerde baselines (FlakiDock) en vanilla LLM's.

4. Experimentele Resultaten

Het framework werd geëvalueerd op de $D^3$ benchmark (653 uitvoerbare instanties na filtering op netwerk-timeouts).

• Reparatie-effectiviteit: Cadre bereikte een reparatiepercentage van 35,22%, waarmee het de regelgebaseerde baseline (Parfum, 9,34%) met 2,78$\times$ versloeg en de beste LLM-gebaseerde baseline (Vanilla-LLM, 28,48%) met 1,24$\times$.
• Token-efficiëntie & Robuustheid: Cadre elimineerde prompt-overflow failures volledig ($|F_r| = 0$), waarbij 95,25% van de prompts onder de 30k tokens bleef. In contrast hiermee faalden concurrerende LLM-methoden in 41–58 gevallen door het overschrijden van de contextlimieten.
• Stale Drift Robuustheid: Naarmate drift-instanties "stale" werden (persisteerden over meerdere commits), degradeerde de prestatie van diff-only benaderingen aanzienlijk. Bij een afstand van 5+ commits behield Cadre een succespercentage van 25,9%, vergeleken met 19,7% voor de beste baseline, wat aantoont dat de CDG een structureel signaal biedt dat robuust is tegen commit-afstand.
• Ablatie-studies: Het verwijderen van de CDG verminderde het reparatiepercentage met 4,29 procentpunten, terwijl het verwijderen van de tweestaps workflow het met 3,67 punten verminderde en prompt-overflow failures opnieuw introduceerde. De componenten bleken elkaar wederzijds te versterken.

5. Betekenis en Claims

Het artikel claimt dat expliciete afhankelijkheidsmodellering een duurzaam reparatiesignaal is. De auteurs stellen dat het voordeel van contextbewuste benaderingen ten opzichte van diff-only of retrieval-gebaseerde methoden groter wordt naarmate de drift ouder wordt over commits heen. De studie suggereert dat contextbewuste Infrastructure as Code (IaC) maintenance een productieve richting is voor toekomstige toolontwikkeling.

De auteurs merken bescheiden de beperkingen op: de CDG is gebaseerd op statische analyse en kan runtime-factoren zoals de staat van package registries of netwerkcondities niet volledig vangen, wat een deel van de onopgeloste fouten verklaart. Daarnaast is de benchmark beperkt tot publieke GitHub-repositories. Desalniettemin vestigt het werk de conclusie dat het expliciet modelleren van de build-context — specifiek de flow van data en controle over instructies heen — cruciaal is voor het automatiseren van de reparatie van evoluerende softwareconfiguraties.