Sintesi Tecnica: Taming the Drift: Context-aware Repair of Dockerfile Drift during Software Evolution

1. Definizione del Problema: Dockerfile Drift

Lo sviluppo di software moderno si affida pesantemente alle pipeline di Continuous Integration e Continuous Deployment (CI/CD), dove Docker funge da standard de facto per garantire ambienti di build riproducibili. Tuttavia, un problema critico noto come Dockerfile drift mina questa affidabilità. Il drift si verifica quando un Dockerfile non riesce ad assorbire i cambiamenti apportati al codice sorgente dell'applicazione, portando a una discrepanza tra lo script di build e lo stato evolutivo del repository. A differenza degli errori di sintassi, il drift è un problema di co-evoluzione interna in cui le informazioni per la riparazione risiedono nello stesso repository che ha prodotto il fallimento.

Il drift si manifesta come percorsi di file errati, variabili d'ambiente non corrispondenti, specifiche di dipendenze obsolete o cambiamenti di piattaforma. Questi fallimenti sono particolarmente difficili da riparare automaticamente a causa di tre sfide principali:

• C1 (Estrazione del Contesto): Lo stato della build (directory di lavoro, variabili d'ambiente, set di file) è determinato dall'esecuzione cumulativa delle istruzioni precedenti, non solo dal testo del Dockerfile. I metodi esistenti, basati su regole o su LLM, spesso trattano il Dockerfile in isolamento, fallendo nel modellare queste interazioni dinamiche.
• C2 (Dipendenze tra le Istruzioni): Le istruzioni spesso dipendono da artefatti prodotti da passaggi precedenti in modi non ovvi (ad esempio, un comando RUN che opera su file introdotti da un precedente COPY o variabili impostate da un ARG). Queste dipendenze non sono sintatticamente visibili in isolamento.
• C3 (Localizzazione delle Cause Radice): I log di errore spesso indicano l'istruzione che è fallita, ma raramente identificano la causa radice, che può derivare da un cambiamento nel codice introdotto in un commit precedente.

2. Metodologia: Il Framework Cadre

Gli autori propongono Cadre, un framework consapevole del contesto progettato per riparare il Dockerfile drift modellando esplicitamente il contesto di build. L'intuizione centrale del design è che la struttura del contesto determina la qualità della riparazione più del volume del contesto. Cadre affronta le tre sfide attraverso quattro fasi integrate:

2.1 Dockerfile Drift Extractor (DodeX)

Per affrontare la mancanza di benchmark realistici, gli autori hanno sviluppato DodeX, una pipeline che estrae istanze di drift reali dai log della CI di GitHub Actions. A differenza dei dataset di snapshot statici, DodeX cattura l'intera configurazione di build, inclusi argomenti di build dinamici, piattaforme target e l'esatto diff del cambiamento del codice che ha scatenato il fallimento. Ciò garantisce che ogni istanza estratta sia localmente riproducibile.

2.2 Instruction-level Context Profiler

Per risolvere C1, Cadre esegue una simulazione stateful del processo di build di Docker. Attraversa il Dockerfile istruzione per istruzione, mantenendo uno Stato di Contesto ($\sigma$) che traccia:

• La directory di lavoro corrente ($\delta$).
• Le variabili d'ambiente risolte ($\varepsilon$).
• L'insieme dei file presenti nel container ($\Phi$).

Fondamentalmente, il profiler impiega parser consapevoli del sistema di build per 11 ecosistemi principali (ad es., Go, Python, npm, Maven). Invece di trattare i comandi RUN come stringhe opache, questi parser inferiscono le dipendenze implicite dei file (ad es., inferendo che go build dipende da go.mod e da tutti i file *.go nella directory). Ciò produce una Instruction Context Map (ICM) che collega ogni istruzione al suo preciso stato al momento della build.

2.3 Context-aware Dependency Graph (CDG)

Per risolvere C2, l'ICM viene convertita in un Context-aware Dependency Graph (CDG), un grafo aciclico diretto ($G = (V, E)$) che rende esplicite le dipendenze tra le istruzioni:

• Vertici: Includono nodi di istruzione ($V_I$) e nodi di file ($V_F$).
• Archi: Includono archi sequenziali ($E_S$) che rappresentano il flusso di controllo ed archi di dataflow ($E_D$) che rappresentano le dipendenze "read-from" tra file e istruzioni.
  Questo grafo permette al sistema di tracciare i percorsi di propagazione del fallimento attraverso i confini delle istruzioni, identificando come un cambiamento in un file sorgente (ad es., go.mod) invalidi una specifica istruzione RUN tramite passaggi intermedi di COPY o ARG.

2.4 Context-refined Repair Workflow

Per risolvere C3 e gestire i limiti di token, Cadre impiega un workflow agentico a due fasi piuttosto che un prompt a colpo singolo:

1. Context Inquiry: L'LLM riceve il log di errore, il diff del codice e una versione ridotta del CDG. Gli viene chiesto di selezionare il set minimo di file rilevanti e parole chiave grep necessari per la riparazione. Questo passaggio filtra il contesto irrilevante prima del caricamento del contenuto dei file.
2. Repair Generation: Il sistema recupera solo i file selezionati e genera una patch mirata.
   Questo approccio evita l'overflow del prompt (un tipico modo di fallimento dei metodi concorrenti basati su LLM) e assicura che il modello si concentri sulle evidenze causalmente rilevanti.

3. Contributi Chiave

• Framework Cadre: Un nuovo framework di riparazione basato sull'intuizione che la struttura del contesto è più preziosa del suo volume. Integra un profiler di contesto stateful, un grafo di dipendenza e un workflow LLM a due fasi.
• DodeX e Benchmark $D^3$: La creazione di DodeX, una pipeline per estrarre istanze di drift con intere configurazioni di build, e $D^3$, il primo benchmark di Dockerfile drift dove tutte le 1.040 istanze sono localmente riproducibili utilizzando i parametri esatti delle build originali della CI.
• Valutazione Empirica: Una valutazione completa che confronta Cadre con baseline basate su regole (Parfum), baseline basate sul recupero (FlakiDock) e LLM vanilla.

4. Risultati Sperimentali

Il framework è stato valutato sul benchmark $D^3$ (653 istanze eseguibili dopo il filtraggio per timeout di rete).

• Efficacia della Riparazione: Cadre ha raggiunto un tasso di riparazione del 35,22%, superando la baseline basata su regole (Parfum, 9,34%) di 2,78$\times$ e la migliore baseline basata su LLM (Vanilla-LLM, 28,48%) di 1,24$\times$.
• Efficienza dei Token e Robustezza: Cadre ha eliminato completamente i fallimenti per overflow del prompt ($|F_r| = 0$), mantenendo il 95,25% dei prompt sotto i 30k token. Al contrario, i metodi LLM concorrenti hanno fallito nel generare patch in 41–58 casi a causa del superamento dei limiti di contesto.
• Robustezza allo Stale Drift: Man mano che le istanze di drift diventavano "stale" (persistenti attraverso più commit), le prestazioni degli approcci basati solo sul diff degradavano significativamente. A una distanza di 5+ commit, Cadre ha mantenuto un tasso di successo del 25,9% rispetto al 19,7% della migliore baseline, dimostrando che il CDG fornisce un segnale strutturale robusto alla distanza dei commit.
• Studi di Ablazione: Rimuovere il CDG ha ridotto il tasso di riparazione di 4,29 punti percentuali, mentre rimuovere il workflow a due fasi lo ha ridotto di 3,67 punti e ha reintrodotto i fallimenti per overflow del prompt. I componenti sono risultati essere mutualmente rinforzanti.

5. Significato e Rivendicazioni

L'articolo sostiene che la modellazione esplicita delle dipendenze è un segnale di riparazione duraturo. Gli autori sostengono che il vantaggio degli approcci consapevoli del contesto rispetto a quelli basati solo sul diff o sul recupero si amplia man mano che il drift invecchia attraverso i commit. Lo studio suggerisce che la manutenzione consapevole del contesto dell'Infrastructure as Code (IaC) è una direzione produttiva per lo sviluppo di strumenti futuri.

Gli autori notano con modestia alcuni limiti: il CDG si basa sull'analisi statica e non può catturare completamente i fattori di runtime come lo stato dei registry dei pacchetti o le condizioni di rete, che spiegano alcuni fallimenti non risolti. Inoltre, il benchmark è limitato ai repository pubblici di GitHub. Tuttavia, il lavoro stabilisce che modellare esplicitamente il contesto di build — specificamente il flusso di dati e di controllo attraverso le istruzioni — è fondamentale per automatizzare la riparazione di configurazioni software in evoluzione.